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" http://librarian.launchpad.net/6931566/missinglibcrash.tar.gz -- Firefox crash https://launchpad.net/bugs/94753 -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
