Crash reports.

[David Farning]

Some random thought on crash reports.  I hope to evolve this into a wiki
mini tutorial for new triagers.

Many crash reports are sent in by very inexperienced users.

Crash reports are useful for pulling out 

DistroRelease: Ubuntu 6.10

and

Package: firefox 2.0.0.1+0dfsg-0ubuntu0.6.10

so there is no need to ask for that information from the user.



If the report has hundreds of lines that say (no debugging symbols found) it is not_symbolized. so it is not all that
useful...yet.  Martin Pitt is developing an application, apport-retrace, that can add debugging information making it
symbolized.  Information about apport can be found at https://wiki.ubuntu.com/Apport and man apport-retrace.

The most useful item in the crash report for us is the stacktrace which tells exactly what the program was doing when 
it crashed. A good introductory article on stacktraces can be found at 
http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/

That article is based on java.  But, all stacktraces are pretty similar.  They give a trace of the functions called
by the program at the point it crashed.  Depending on the language the each line shows the the filename and function
name of each function called.  the functions are in reverse order below is an example from
 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/74576

Stacktrace:
 Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
 Core was generated by `/usr/lib/firefox/firefox-bin'.
 Program terminated with signal 11, Segmentation fault.
 #0  0xffffe410 in __kernel_vsyscall ()
 #0  0xffffe410 in __kernel_vsyscall ()
 No symbol table info available.
 #1  0xb7e28651 in raise () from /lib/tls/i686/cmov/libpthread.so.0
 No symbol table info available.
 #2  0x08057556 in nsProfileLock::FatalSignalHandler (signo=-1209876492)
     at nsProfileLock.cpp:206
 	unblock_sigs = {__val = {1024, 0 <repeats 31 times>}}
 	oldact = <value optimized out>
 #3  <signal handler called>
 No symbol table info available.
 #4  0xb7c76c24 in gtk_style_realize (style=0x85cf800, colormap=0x0)
     at gtkstyle.c:839
 No locals.
 #5  0xb7c7a1f0 in IA__gtk_style_attach (style=0x9afea00, window=0x879ca80)
     at gtkstyle.c:752
 	styles = <value optimized out>
 	new_style = <value optimized out>
 	colormap = (GdkColormap *) 0x0
 	__PRETTY_FUNCTION__ = "IA__gtk_style_attach"
 #6  0xb7d20fe2 in gtk_widget_set_style_internal (widget=0x89bf158, 
     style=0x9afea00, initial_emission=0) at gtkwidget.c:5138
 	previous_style = (GtkStyle *) 0x812f258
 #7  0xb7d2113a in reset_rc_styles_recurse (widget=0x89bf158, data=0x0)
     at gtkwidget.c:5348
 No locals.
 #8  0xb68479a3 in moz_container_forall (container=0x8295a40, 
     include_internals=1, callback=0xb7d210d0 <reset_rc_styles_recurse>, 
     callback_data=0x0) at mozcontainer.c:401
 	child = <value optimized out>
 	tmp_list = (GList *) 0x0
 	__PRETTY_FUNCTION__ = "moz_container_forall"
 #9  0xb7b725fb in IA__gtk_container_forall (container=0x8295a40, 
     callback=0xb7d210d0 <reset_rc_styles_recurse>, callback_data=0x0)
     at gtkcontainer.c:1261
 	__PRETTY_FUNCTION__ = "IA__gtk_container_forall"
 #10 0xb7d21129 in reset_rc_styles_recurse (widget=0x8295a40, data=0x0)
     at gtkwidget.c:5351
 No locals.
  
The trace is in reverse order.  So the last thing to have happened is on the top.  with a little practice you can
start recognizing functions that appear frequently near crashes.

In this case I believe that gtk_style_realize is the problem so I googled for it.  I found a reference in an
upstream bug track and started looking for similarities to our case.  Yippy! a match in this case.

David  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-mozillateam/attachments/20070121/bdc57b5e/attachment.pgp