Skip to content

Latest commit

 

History

History
82 lines (58 loc) · 3.17 KB

memory-debugging.md

File metadata and controls

82 lines (58 loc) · 3.17 KB

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. And 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 will 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-debug is given both features will be 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 a 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 will also make sense to build libcurl with the debug option (usually -g to 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.

Modify Your Application

Add a line in your application code:

  curl_dbg_memdebug("dump");

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 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.