lib/memdebug.ccontains debug-versions of a few functions. Functions such as
fclose(), etc that somehow deal with resources that might give us problems if we "leak" them. The functions in the memdebug system do nothing fancy, they do their normal function and then log information about what they just did. The logged data can then be analyzed after a complete session,
memanalyze.plis the perl script present in
tests/that analyzes a log file generated by the memory tracking system. It detects if resources are allocated but never freed and other kinds of errors related to resource management.
Internally, the definition of the preprocessor symbol
DEBUGBUILDrestricts code which is only compiled for debug enabled builds. And symbol
CURLDEBUGis used to differentiate code which is only used for memory tracking/debugging.
-DCURLDEBUGwhen compiling to enable memory debugging, this is also switched on by running configure with
-DDEBUGBUILDwhen compiling to enable a debug build or run configure with
curl --versionwill list 'Debug' feature for debug enabled builds, and will list 'TrackMemory' feature for curl debug memory tracking capable builds. These features are independent and can be controlled when running the configure script. When
--enable-debugis given both features will be enabled, unless some restriction prevents memory tracking from being used.
... using the memory debug system. In general, we suggest using valgrind a the first choice.
Please note that this memory leak system is not adjusted to work in more than one thread. If you want/need to use it in a multi-threaded app. Please adjust accordingly.
Rebuild libcurl with
-DCURLDEBUG(usually, rerunning configure with
make cleanfirst, then
makeso that all files are actually rebuilt properly. It will also make sense to build libcurl with the debug option (usually
-gto the compiler) so that debugging it will be easier if you actually do find a leak in the library.
This will create a library that has memory debugging enabled.
Add a line in your application code:
This will make the malloc debug system output a full trace of all resources using functions to the given file name. Make sure you rebuild your program and that you link with the same libcurl you built for this purpose as described above.
Run your program as usual. Watch the specified memory trace file grow.
Make your program exit and use the proper libcurl cleanup functions etc. So that all non-leaks are returned/freed properly.
tests/memanalyze.plperl script to analyze the dump file:
This now outputs a report on what resources that were allocated but never freed etc. This report is fine for posting to the list.
If this does not produce any output, no leak was detected in libcurl. Then the leak is mostly likely to be in your code.