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.
 |