Re: seems like this would help (gdb stack traces)

[Nils Philippsen <nils wombat dialup fht-esslingen de>]

On Wed, 20 Jan 1999, Rebecca Ore wrote:

> On Wed, Jan 20, 1999 at 03:00:22PM -0500, Brian M Dial wrote:
> > It'd be nice if someone would put together a simple page on howto use the
> > common debugging tools to get the best bug report for programs in gnome. 
> > Nothing as complex as the man pages for gdb or backtrace or anything (that
> > would discourage people from reading it <g>)  This would easily cut down the
> > mail of  <user> I keep getting segfaults   <developer> send some backtraces 
> > <user> here's the backtraces  <developer> that's not what we need, send this
> > etc....
> > 
> > Anyone feel up to the task?
> 
> Someone sent me a letter yesterday explaining what I'd been doing wrong
> in clear terms (I'd been using the XEmacs instructions for getting a
> stack trace which turned out to be more XEmacs specific than I'd realized).
> 
> If he'd post that here, we could see if all the tarballistas found the
> instructions useful and if the developers then found the stack traces
> useful.  There was an earlier letter about what information beyond the

Here we go:

The two basic problems (in fact it's one that triggers another) are:

- Invocation of gdb without the correct path two the program binary, which
  leads to
- gdb running with nothing except the core dump itself, thus no debugging
  symbols are available, so all you get when doing a backtrace ("bt"/ 
  "where") are some mem addresses in hex which are not really beautiful
  (and informative)

The better procedure would be:

1) Do I know the correct name of the program binary? If yes, goto 3)
2) run "gdb -c core", the output should contain a line similar to:

   Core was generated by `myprogram arg1 arg2 arg3'.

   "myprogram" is the binary itself, arg1, arg2 and arg3 are the program's
   arguments which are not interesting to gdb (they might be interesting
   to the developer, though).

   Now we can continue (or goto step 1) if we're really paranoid).
3) With the binary name we can run gdb and get our stack trace:

   ----8<----
   gdb `which myprogram` core
   [Snipped a lot of gdb output about missing symbols in libraries, etc.]
   (gdb) bt
   #0  0x401c22de in __select ()
   #1  0x4006b96c in __DTOR_END__ ()
   #2  0x40046fb0 in _XtWaitForSomething ()
   #3  0x4004806f in XtAppNextEvent ()
   #4  0x4003dd57 in XtAppMainLoop ()
   #5  0x8049150 in _start ()
   ----8<----

   Whether you use "bt" (backtrace) or "where" doesn't make a difference
   AFAIK (someone correct me please, if this is wrong).

   The backticks ("`which myprogram") are important, they're _not_ 
   apostrophes (When magnified the would rather look like a backslash
   ("\") than a slash ("/")).
4) Now send the trace along with a description of how you triggered the
   core dump to the developer or the list.

> trace needed to go in the bug reports -- combine all and put on the web
> site.
> 
> Re another post on checking the tarballs: I think all we could expect is
> that someone *might* have the time to see if they compiled and installed.

Yes, this really would be nice :-)

Bye,
Nils
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen                  @college: nils@fht-esslingen.de
Vogelsangstrasse 115             @home:    nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart                phone:    +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lottery is a tax on people who are bad at math.