mirror of
https://github.com/curl/curl.git
synced 2025-04-06 16:10:34 +08:00
20005a83d2
fix the CONNECT authentication code with multi-pass auth methods (such as NTLM) as it didn't previously properly ignore response-bodies - in fact it stopped reading after all response headers had been received. This could lead to libcurl sending the next request and reading the body from the first request as response to the second request. (I also renamed the function, which wasn't strictly necessary but...) The best fix would to once and for all make the CONNECT code use the ordinary request sending/receiving code, treating it as any ordinary request instead of the special-purpose function we have now. It should make it better for multi-interface too. And possibly lead to less code... Added test case 265 for this. It doesn't work as a _really_ good test case since the test proxy is too stupid, but the test case helps when running the debugger to verify.
$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.