GDB shows the wrong thread in postmortem analysis

I am experiencing a strange behavior of GDB. When running a post-mortem analysis of a core, dumped from a heavily multithreaded application in c++, the debugger commands

bt
where
thread info

never tell me the thread which the program actually crashed. It keeps showing me the thread number 1. As I am used to see this working from other Systems, I am curious if is is a Bug in GDB or if they changed the behavior somehow. Can anyone point me to a solution of this, it is PITA to search through 75 Threads, just to find out something the Debugger already knows.

By the way, I am on Debian Squeeze (6.0.1), the version of GDB is 7.0.1-debian, the System is x86 and compl开发者_开发技巧etely 32-Bit. On my older Debian (5.x) installation, debugging a core, dumped by the exact same source, delivers me a backtrace of the correct thread, as does GDB on a Ubuntu 10.04 installation.

Thanks!

GDB does not know which thread caused the crash, and simply shows the first thread that it sees in the core.

The Linux kernel usually dumps the faulting thread first, and that is why on most systems you end up in exactly the correct thread once you load core into GDB.

I've never seen a kernel where this was broken, but I've never used Debian 6 either.

My guess would be that this was broken, and then got fixed, and Debian 6 shipped with a broken kernel.

You could try upgrading the kernel on your Debian 6 machine to match e.g. your Ubuntu 10.04, and see if the problem disappears.

Alternatively, Google user-space coredumper does it correctly. You can link it in, and call it from SIGSEGV handler.