A crash reporter

Casey Ho pidgin at caseyho.com
Wed Feb 11 00:38:44 EST 2009

I've been working this past month on a proof-of-concept crash
reporter, and I'm happy to say it's nearly complete.

My motivation for working on this:
* There is no good way to get crash reports from Pidgin users, unless
they actually have gdb and/or a debug version installed.
* Lots of Pidgin crashes are random (i.e. random crash overnight).
Plenty of users give up on finding a trace.
* Lots of crashes are caused by poorly written plugins, but users have
trouble telling the difference.

To implement this, I looked at Google Breakpad.  Some background:
* Google Breakpad is a cross platform crash handling library.
Breakpad dumps a file in a standard format on a crash, which can be
used to retrieve a stack trace and other goodies.
* In a simple case, Breakpad can detect the offending .so/.dll that
caused a crash without symbol data
* In an extreme case, Breakpad dumps can be matched with symbol tables
server side for analysis
* Breakpad is used in Firefox and Gnome Bug Buddy

I've completed a simple proof of concept crash handler which dumps a
file upon SIGSEGV.  The handler also forks a new process which then
prints a stack trace.  Ideally the new process can grab additional
data such as what plugins a user has installed and what protocols are
enabled.  Even without reporting these dumps server side, the user can
immediately be told what protocol or plugin crashed (so blame is
correctly placed).  This is all without the need for a seperate GDB
process or a special compile with debugging symbols.

How do people feel about adding an automated crash reporter/processing
program to Pidgin?  I think there's huge value in being able to
immediately inform the user what plugin/protocol crashed without
having to either install debug tools or wait to reproduce it.

The main caveat is that Breakpad is a C++ program that depends on
libstdc++.  I wrangled with automake and autoconf to make sure Pidgin
will work as normal if C++/stdc++ aren't available (effectively making
stdc++ an optional dependency).  But even then, how do you developers
feel about including some amount of C++ code?


You can see the diff at http://caseyho.com/misc/pidgin/

To keep the size down, the Breakpad code is omitted.  If you want to
compile this, just download the Breakpad code and paste it in.

Limitations: This is only set up for Linux so far.  No Windows,
although the code exists.


Sample crash output data:

Operating system: Linux
                  0.0.0 Linux #1
SMP Tue Nov 25 21:45:59 PST 2008 x86_64 GNU/Linux
CPU: x86
     GenuineIntel family 10 model 15 stepping 6
     2 CPUs

Crash reason:  SIGSEGV
Crash address: 0xf74074bc

Thread 0 (crashed)
 0  crashingplugin.so + 0x4bc
    eip = 0xf74074bc   esp = 0xffffb4b0   ebp = 0xffffb4b8   ebx = 0xf7408714
    esi = 0x00000001   edi = 0x082e1510   eax = 0x00000014   ecx = 0x00000000
    edx = 0x4d7ac7c0   efl = 0x00010246
 1  libpurple.so.0.5.5 + 0x49b1c
    eip = 0xf7f92b1d   esp = 0xffffb4c0   ebp = 0xffffb4f8
 2  libpurple.so.0.5.5 + 0x4b48f
    eip = 0xf7f94490   esp = 0xffffb500   ebp = 0xffffb528
 3  lt-pidgin + 0x7ebbd
    eip = 0x080c6bbe   esp = 0xffffb530   ebp = 0xffffd708
 4  libc-2.3.6.so + 0x14ec1
    eip = 0x4d691ec2   esp = 0xffffd710   ebp = 0xffffd768

Loaded modules:
0x08048000 - 0x0811afff  lt-pidgin  ???  (main)
0x0811b000 - 0x0811efff  lt-pidgin  ???
0x41000000 - 0x41003fff  libgtkspell.so.0.0.0  ???
0x41004000 - 0x41004fff  libgtkspell.so.0.0.0  ???

More information about the Devel mailing list