mirror of
https://github.com/moparisthebest/curl
synced 2025-03-01 09:51:46 -05:00
6fdbb01194
(http://curl.haxx.se/bug/view.cgi?id=1431750) helped me identify and fix two different but related bugs: 1) Removing an easy handle from a multi handle before the transfer is done could leave a connection in the connection cache for that handle that is in a state that isn't suitable for re-use. A subsequent re-use could then read from a NULL pointer and segfault. 2) When an easy handle was removed from the multi handle, there could be an outstanding c-ares DNS name resolve request. When the response arrived, it caused havoc since the connection struct it "belonged" to could've been freed already. Now Curl_done() is called when an easy handle is removed from a multi handle pre-maturely (that is, before the transfer was complteted). Curl_done() also makes sure to cancel all (if any) outstanding c-ares requests.
$Id$
_ _ ____ _
___| | | | _ \| |
/ __| | | | |_) | |
| (__| |_| | _ <| |___
\___|\___/|_| \_\_____|
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("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.