From 4ec04015295308c728d57e8a52f0b68189d69f94 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Mon, 3 Dec 2001 09:44:11 +0000 Subject: [PATCH] modified the stack trace section slightly --- docs/BUGS | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/docs/BUGS b/docs/BUGS index 2d703767c..8b6fefd3a 100644 --- 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 ' curl core'. 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.