modified the stack trace section slightly

diff --git a/docs/BUGS b/docs/BUGS
index 2d703767c9abcfbe0a841589fc93b521ee58e5d9..8b6fefd3a544c95b184ecb595d4b39be8f294ba4 100644 (file)
--- a/docs/BUGS
+++ b/docs/BUGS
@@ -1,3 +1,4 @@
+$Id$
                                   _   _ ____  _     
                               ___| | | |  _ \| |    
                              / __| | | | |_) | |    
@@ -35,23 +36,24 @@ BUGS
   The address and how to subscribe to the mailing list is detailed in the
   MANUAL file.
 
-  HOW TO GET A STACK TRACE with a common unix debugger
-  ====================================================
+  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.
+  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 bangs.
+  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, you can give the compiler instructions. Enter 'where' (without the
-  quotes) and press return.
+  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.
+  crashed. Include the stack trace with your detailed bug report. It'll help a
+  lot.