diff options
author | Kirill Volinsky <mataes2007@gmail.com> | 2013-11-10 18:02:01 +0000 |
---|---|---|
committer | Kirill Volinsky <mataes2007@gmail.com> | 2013-11-10 18:02:01 +0000 |
commit | ac48668a549fe76648e0ac3f93c9943383e043f5 (patch) | |
tree | bcfcf258bd003db20b1ee41fbbff173c8f340031 /plugins/FTPFileYM/curl/lib/README.memoryleak | |
parent | 64e1340acd813704c9e9009b0a4e6fc9a3fb5adf (diff) |
curl folder renamed
git-svn-id: http://svn.miranda-ng.org/main/trunk@6858 1316c22d-e87f-b044-9b9b-93d7a3e3ba9c
Diffstat (limited to 'plugins/FTPFileYM/curl/lib/README.memoryleak')
-rw-r--r-- | plugins/FTPFileYM/curl/lib/README.memoryleak | 55 |
1 files changed, 55 insertions, 0 deletions
diff --git a/plugins/FTPFileYM/curl/lib/README.memoryleak b/plugins/FTPFileYM/curl/lib/README.memoryleak new file mode 100644 index 0000000000..166177794f --- /dev/null +++ b/plugins/FTPFileYM/curl/lib/README.memoryleak @@ -0,0 +1,55 @@ + _ _ ____ _ + ___| | | | _ \| | + / __| | | | |_) | | + | (__| |_| | _ <| |___ + \___|\___/|_| \_\_____| + + 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. |