mirror of
https://github.com/moparisthebest/curl
synced 2024-12-21 23:58:49 -05:00
my first take at a memory leak detection document
This commit is contained in:
parent
94bae20776
commit
fc4d1d9a60
@ -7,7 +7,7 @@ AUTOMAKE_OPTIONS = foreign nostdinc
|
|||||||
EXTRA_DIST = getdate.y Makefile.b32 Makefile.b32.resp Makefile.m32 \
|
EXTRA_DIST = getdate.y Makefile.b32 Makefile.b32.resp Makefile.m32 \
|
||||||
Makefile.vc6 Makefile.riscos libcurl.def dllinit.c curllib.dsp \
|
Makefile.vc6 Makefile.riscos libcurl.def dllinit.c curllib.dsp \
|
||||||
curllib.dsw config-vms.h config-win32.h config-riscos.h config-mac.h \
|
curllib.dsw config-vms.h config-win32.h config-riscos.h config-mac.h \
|
||||||
config.h.in ca-bundle.crt README.encoding
|
config.h.in ca-bundle.crt README.encoding README.memoryleak
|
||||||
|
|
||||||
lib_LTLIBRARIES = libcurl.la
|
lib_LTLIBRARIES = libcurl.la
|
||||||
|
|
||||||
|
49
lib/README.memoryleak
Normal file
49
lib/README.memoryleak
Normal file
@ -0,0 +1,49 @@
|
|||||||
|
$Id$
|
||||||
|
_ _ ____ _
|
||||||
|
___| | | | _ \| |
|
||||||
|
/ __| | | | |_) | |
|
||||||
|
| (__| |_| | _ <| |___
|
||||||
|
\___|\___/|_| \_\_____|
|
||||||
|
|
||||||
|
How To Track Down Suspected Memory Leaks in libcurl
|
||||||
|
===================================================
|
||||||
|
|
||||||
|
Build
|
||||||
|
|
||||||
|
Rebuild libcurl with -DMALLOCDEBUG (usually, rerunning configure with
|
||||||
|
--enable-debug fixes this). 'make clean' first, then 'make' so that all
|
||||||
|
files actually are 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_memdebug("filename");
|
||||||
|
|
||||||
|
This will make the malloc debug system output a full trace of all resource
|
||||||
|
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 memdump file:
|
||||||
|
|
||||||
|
tests/memanalyze.pl < memdump
|
||||||
|
|
||||||
|
This now outputs a report on what resources that were allocated but never
|
||||||
|
freed etc. This report is very fine for posting to the list!
|
||||||
|
|
||||||
|
If this doesn't produce any output, no leak was detected in libcurl. Then
|
||||||
|
the leak is mostly likely to be in your code.
|
Loading…
Reference in New Issue
Block a user