Files correlati : Commento : Spostamento in libraries delle librerie esterne di Campo per una maggiore pulizia e organizzazione git-svn-id: svn://10.65.10.50/branches/R_10_00@24150 c028cbd2-c16b-5b4b-a496-9718f37d4682
		
			
				
	
	
		
			56 lines
		
	
	
		
			1.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			56 lines
		
	
	
		
			1.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
|                                   _   _ ____  _
 | |
|                               ___| | | |  _ \| |
 | |
|                              / __| | | | |_) | |
 | |
|                             | (__| |_| |  _ <| |___
 | |
|                              \___|\___/|_| \_\_____|
 | |
| 
 | |
|              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.
 |