mirror of
https://github.com/curl/curl.git
synced 2024-11-21 01:16:58 +08:00
80 lines
3.3 KiB
Plaintext
80 lines
3.3 KiB
Plaintext
$Id$
|
|
_ _ ____ _
|
|
___| | | | _ \| |
|
|
/ __| | | | |_) | |
|
|
| (__| |_| | _ <| |___
|
|
\___|\___/|_| \_\_____|
|
|
|
|
BUGS
|
|
|
|
Curl and libcurl have grown substantially since the beginning. At the time
|
|
of writing (end of April 2002), there are 32000 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.
|
|
|
|
WHERE TO REPORT
|
|
|
|
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
|
|
|
|
(but please read the section below first before doing that)
|
|
|
|
WHAT TO REPORT
|
|
|
|
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 behavior. You therefore need to tell us:
|
|
|
|
- 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 (if possible), at least which protocol
|
|
|
|
and anything and everything else you think matters. Tell us what you
|
|
expected to happen, tell use what did happen, tell us how you could make it
|
|
work another way. Dig around, try out, test. Then include all the tiny bits
|
|
and pieces in your report. You will benefit from this yourself, as it will
|
|
enable us to help you quicker and more accurately.
|
|
|
|
Since curl deals with networks, it often helps us if you include a protocol
|
|
debug dump with your bug report. The output you get by using the -v
|
|
flag. Usually, you also get more info by using -i so that is likely to be
|
|
useful when reporting bugs as well.
|
|
|
|
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
|
|
|
|
First, you must make sure that you compile all sources with -g and that you
|
|
don't 'strip' the final executable. Try to avoid optimizing the code as
|
|
well, remove -O, -O2 etc from the compiler options.
|
|
|
|
Run the program until it dumps core.
|
|
|
|
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, 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. Include the stack trace with your detailed bug report. It'll help a
|
|
lot.
|
|
|