The file lib/memdebug.c contains debug-versions of a few functions.
Functions such as malloc(), free(), fopen(), 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.pl is 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 DEBUGBUILD restricts
code which is only compiled for debug enabled builds. The symbol CURLDEBUG
is used to differentiate code which is only used for memory
tracking/debugging.
Use -DCURLDEBUG when compiling to enable memory debugging, this is also
switched on by running configure with --enable-curldebug. Use
-DDEBUGBUILD when compiling to enable a debug build or run configure with
--enable-debug.
curl --version lists the Debug feature for debug enabled builds, and lists
the TrackMemory feature for curl debug memory tracking capable builds. These
features are independent and can be controlled when running the configure
script. When --enable-debug is given both features get enabled, unless some
restriction prevents memory tracking from being used.
... using the memory debug system. In general, we suggest using valgrind as 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
--enable-debug fixes this). make clean first, then make so that all
files are actually rebuilt properly. It also makes sense to build libcurl with
the debug option (usually -g to the compiler) so that debugging gets
easier if you actually do find a leak in the library.
This builds a library that has memory debugging enabled.
Add a line in your application code:
curl_dbg_memdebug("dump");
This makes the malloc debug system output a full trace of all resources using functions to the given filename. 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.
Use the tests/memanalyze.pl Perl script to analyze the dump file:
$ tests/memanalyze.pl dump
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.