diff options
author | Daniel Stenberg <daniel@haxx.se> | 2000-03-17 11:45:20 +0000 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2000-03-17 11:45:20 +0000 |
commit | b4fc921a0a21ce323fb6f6c5659c807158ea928e (patch) | |
tree | df5e14093f8dbc7c0e9e3b4e225d73a969070d0a /BUGS | |
parent | 339bdd1e08d57dc628cc79daef671cc6c4b03165 (diff) |
how to report curl bugs!
Diffstat (limited to 'BUGS')
-rw-r--r-- | BUGS | 56 |
1 files changed, 56 insertions, 0 deletions
@@ -0,0 +1,56 @@ + _ _ ____ _ + ___| | | | _ \| | + / __| | | | |_) | | + | (__| |_| | _ <| |___ + \___|\___/|_| \_\_____| + +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 + + https://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 '<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 finnished 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 chaing of functions that were called when curl + crashed. + |