[Bug 94753] Re: Firefox crash

Johan Walles johan.walles at gmail.com
Sun Mar 25 10:51:24 UTC 2007

I'm not saying libc is buggy, I'm saying the crash happened inside of
libc.  That can happen if somebody passes bogus parameters to vfprintf()
for example, without libc being buggy.

Generally you can trust #0 frames to at least be in the correct library,
since the stack unwinder hasn't had to walk anywhere for frame #0.  If
the unwinder has problems with frame #0 it may or may not be able to
walk out of it and end up in the correct place.  So all bets are off for
the following frames if one frame is problematic.

To find problems with crashes inside of libc the unwinder needs to be
able to unwind libc code.  The unwinder doesn't seem to be able to do
that in this case.  You most probably have -dbgsym packages for libc, so
it'd surprize me if the problem is that those are missing.  Your
retracing thingy needs to tell the unwinder about those though, and the
unwinder needs to be able to use them, and one of those things may not
work very well here.

I made a small test case (attached) to see what happens when trying to
look at a core file when a library in which we have crashed is missing:

(gdb) bt
#0  0xb7f47503 in ?? ()

Compare that to what you get from the core file:
#0 0xb7785e09 in vfprintf () from /lib/tls/i686/cmov/libc.so.6

Doing this on a Debian Testing system (at home now, only running Ubuntu
at work), so YMMV.  Test script is attached though, so you can verify on
your system.

Anyway, as long as you guys are unable to unwind the libc code involved
in this crash I don't expect to be able to do any better :-(.

** Attachment added: "gdb vs missing lib, run ./testmissinglib.sh"

Firefox crash

More information about the Ubuntu-mozillateam-bugs mailing list