how to report curl bugs!

diff --git a/BUGS b/BUGS
new file mode 100644 (file)
index 0000000..469bf24
--- /dev/null
+++ b/BUGS
@@ -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.
+