58 lines
		
	
	
		
			2.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			58 lines
		
	
	
		
			2.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
                                  _   _ ____  _     
 | 
						|
                              ___| | | |  _ \| |    
 | 
						|
                             / __| | | | |_) | |    
 | 
						|
                            | (__| |_| |  _ <| |___ 
 | 
						|
                             \___|\___/|_| \_\_____|
 | 
						|
 | 
						|
BUGS
 | 
						|
 | 
						|
  Curl and libcurl have grown substantially since the beginning. At the time
 | 
						|
  of writing (mid March 2001), there are 23000 lines of source code, and by
 | 
						|
  the time you read this it has probably grown even more.
 | 
						|
 | 
						|
  Of course there are lots of bugs left. And lots of misfeatures.
 | 
						|
 | 
						|
  To help us make curl the stable and solid product we want it to be, we need
 | 
						|
  bug reports and bug fixes. If you can't fix a bug yourself and submit a fix
 | 
						|
  for it, try to report an as detailed report as possible to the curl mailing
 | 
						|
  list to allow one of us to have a go at a solution. You should also post
 | 
						|
  your bug/problem at curl's bug tracking system over at
 | 
						|
 | 
						|
        http://sourceforge.net/bugs/?group_id=976
 | 
						|
 | 
						|
  When reporting a bug, you should include information that will help us
 | 
						|
  understand what's wrong, what you expected to happen and how to repeat the
 | 
						|
  bad behaviour. You therefore need to supply your operating system's name and
 | 
						|
  version number (uname -a under a unix is fine), what version of curl you're
 | 
						|
  using (curl -V is fine), what URL you were working with and anything else
 | 
						|
  you think matters.
 | 
						|
 | 
						|
  If curl crashed, causing a core dump (in unix), there is hardly any use to
 | 
						|
  send that huge file to anyone of us. Unless we have an exact same system
 | 
						|
  setup as you, we can't do much with it. What we instead ask of you is to get
 | 
						|
  a stack trace and send that (much smaller) output to us instead!
 | 
						|
 | 
						|
  The address and how to subscribe to the mailing list is detailed in the
 | 
						|
  MANUAL file.
 | 
						|
 | 
						|
  HOW TO GET A STACK TRACE with a common unix debugger
 | 
						|
  ====================================================
 | 
						|
 | 
						|
  First, you must make sure that you compile all sources with -g and that you
 | 
						|
  don't 'strip' the final executable.
 | 
						|
 | 
						|
  Run the program until it bangs.
 | 
						|
 | 
						|
  Run your debugger on the core file, like '<debugger> curl core'. <debugger>
 | 
						|
  should be replaced with the name of your debugger, in most cases that will
 | 
						|
  be 'gdb', but 'dbx' and others also occur.
 | 
						|
 | 
						|
  When the debugger has finished loading the core file and presents you a
 | 
						|
  prompt, you can give the compiler instructions. Enter 'where' (without the
 | 
						|
  quotes) and press return.
 | 
						|
 | 
						|
  The list that is presented is the stack trace. If everything worked, it is
 | 
						|
  supposed to contain the chain of functions that were called when curl
 | 
						|
  crashed.
 | 
						|
 |