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.
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.
-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.
tests/memanalyze.plperl script to analyze the dump file: