summaryrefslogtreecommitdiff
path: root/plugins/FTPFileYM/curl/lib/README.memoryleak
diff options
context:
space:
mode:
authorKirill Volinsky <mataes2007@gmail.com>2013-11-10 18:02:01 +0000
committerKirill Volinsky <mataes2007@gmail.com>2013-11-10 18:02:01 +0000
commitac48668a549fe76648e0ac3f93c9943383e043f5 (patch)
treebcfcf258bd003db20b1ee41fbbff173c8f340031 /plugins/FTPFileYM/curl/lib/README.memoryleak
parent64e1340acd813704c9e9009b0a4e6fc9a3fb5adf (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.memoryleak55
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.