summaryrefslogtreecommitdiff
path: root/Build/source/libs/curl/docs/BUGS
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/libs/curl/docs/BUGS')
-rw-r--r--Build/source/libs/curl/docs/BUGS63
1 files changed, 63 insertions, 0 deletions
diff --git a/Build/source/libs/curl/docs/BUGS b/Build/source/libs/curl/docs/BUGS
new file mode 100644
index 00000000000..c4f52cf72bf
--- /dev/null
+++ b/Build/source/libs/curl/docs/BUGS
@@ -0,0 +1,63 @@
+$Id: BUGS,v 1.4 2002/01/10 07:38:53 bagder Exp $
+ _ _ ____ _
+ ___| | | | _ \| |
+ / __| | | | |_) | |
+ | (__| |_| | _ <| |___
+ \___|\___/|_| \_\_____|
+
+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 behavior. 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.
+
+ Since curl deals with networks, it often helps us a lot 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.
+