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 2.6.18.5-gg42workstation-mixed64-32 #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