1 _ _ ____ _ 2 ___| | | | _ \| | 3 / __| | | | |_) | | 4 | (__| |_| | _ <| |___ 5 \___|\___/|_| \_\_____| 6 7 How To Track Down Suspected Memory Leaks in libcurl 8 =================================================== 9 10Single-threaded 11 12 Please note that this memory leak system is not adjusted to work in more 13 than one thread. If you want/need to use it in a multi-threaded app. Please 14 adjust accordingly. 15 16 17Build 18 19 Rebuild libcurl with -DCURLDEBUG (usually, rerunning configure with 20 --enable-debug fixes this). 'make clean' first, then 'make' so that all 21 files actually are rebuilt properly. It will also make sense to build 22 libcurl with the debug option (usually -g to the compiler) so that debugging 23 it will be easier if you actually do find a leak in the library. 24 25 This will create a library that has memory debugging enabled. 26 27Modify Your Application 28 29 Add a line in your application code: 30 31 curl_memdebug("dump"); 32 33 This will make the malloc debug system output a full trace of all resource 34 using functions to the given file name. Make sure you rebuild your program 35 and that you link with the same libcurl you built for this purpose as 36 described above. 37 38Run Your Application 39 40 Run your program as usual. Watch the specified memory trace file grow. 41 42 Make your program exit and use the proper libcurl cleanup functions etc. So 43 that all non-leaks are returned/freed properly. 44 45Analyze the Flow 46 47 Use the tests/memanalyze.pl perl script to analyze the dump file: 48 49 tests/memanalyze.pl dump 50 51 This now outputs a report on what resources that were allocated but never 52 freed etc. This report is very fine for posting to the list! 53 54 If this doesn't produce any output, no leak was detected in libcurl. Then 55 the leak is mostly likely to be in your code. 56