Re: triaging and marking dups - a warning and advice

[Wayne Schuller <k_wayne linuxpower org>]

hi all, 

On Tue, 2002-02-26 at 13:22, Gregory Leblanc wrote: 
> I remember rumors about instructions on how to figure out what the
> crashing function was, but I've never seen them.  How do I figure this
> out?

Naively, it is normally the last function in the stack trace before
gnome_segv_handle is called (for gnome apps only of course). 

Eg: consider this following backtrace snippet: 

Debugging Information: 

(no debugging symbols found)...0x40596c09 in __wait4 () from 
/lib/libc.so.6 
#0  0x40596c09 in __wait4 () from /lib/libc.so.6 
#1  0x40612fd0 in __DTOR_END__ () from /lib/libc.so.6 
#2  0x40176456 in gnome_segv_handle (signum=11) at gnome-init.c:659 
#3  <signal handler called> 
#4  0x0806da4f in init_menus () at eval.c:41 
#5  0x0805d1cf in main () at eval.c:41 

I would say the crashing function is init_menus. 

So this bug should go in a report with similar dups and a summary like: 
"Panel crash on login [ init_menus ] " 

Sometimes it is obvious (to a programmer) that the dodgy function is
called earlier, and the last function before the gnome_segv_handle is
merely along for the ride. 

In this case I do a summary like: 
"Panel crash on lgoin [ dodgy_func -> last_func ] 

and sometimes there are a whole series of similar functions which crash,
like in 59500. this has a wildcard in the square brackets [ gwmh_* ] 

all this stuff makes the data on bugzilla more readable, and helps find
the dup lists for a particular crash quicker. 

And the clearer the information is sorted, the easier it is to catch the
bugs, and the more beautiful desktop enviroment we have, and world
domination comes quicker. :) 

thanks, 
wayne