From 4341671545dd1489a198a5fd66a69b02ef97bddf Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Mon, 22 May 2000 17:33:31 +0000 Subject: moved to the new docs/ directory --- BUGS | 56 -------------------------------------------------------- 1 file changed, 56 deletions(-) delete mode 100644 BUGS (limited to 'BUGS') diff --git a/BUGS b/BUGS deleted file mode 100644 index 5666c969c..000000000 --- a/BUGS +++ /dev/null @@ -1,56 +0,0 @@ - _ _ ____ _ - ___| | | | _ \| | - / __| | | | |_) | | - | (__| |_| | _ <| |___ - \___|\___/|_| \_\_____| - -BUGS - - Curl has grown substantially from that day, several years ago, when I - started fiddling with it. When I write this, there are 16500 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's expected and how to repeat it. 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 - README.curl 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 ' curl core'. - 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. - -- cgit v1.2.3