57 lines
2.0 KiB
Plaintext
57 lines
2.0 KiB
Plaintext
$Id: README.memoryleak,v 1.4 2006-10-29 23:00:52 bagder Exp $
|
|
_ _ ____ _
|
|
___| | | | _ \| |
|
|
/ __| | | | |_) | |
|
|
| (__| |_| | _ <| |___
|
|
\___|\___/|_| \_\_____|
|
|
|
|
How To Track Down Suspected Memory Leaks in libcurl
|
|
===================================================
|
|
|
|
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 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("dump");
|
|
|
|
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 dump file:
|
|
|
|
tests/memanalyze.pl dump
|
|
|
|
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.
|