Memory debugging

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.

Track Down Memory Leaks

... using the memory debug system. In general, we suggest using valgrind as the first choice.

Single-threaded

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.

Build

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.

Modify Your Application

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 Application

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.

Analyze the Flow

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.