| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455 |
- _ _ ____ _
- ___| | | | _ \| |
- / __| | | | |_) | |
- | (__| |_| | _ <| |___
- \___|\___/|_| \_\_____|
- 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.
|
