GDB very often attaches to wrong thread (main thread)

[stippi]

It seems that recently, GDB will attach itself to the main thread when an application crashes in one of it's other threads. I usually go into KDL at this point and try the stack trace of a couple of other threads until I find the one that has really crashed. That's why we get a lot of reports here in Trac that show a BApplication looper waiting for the next message or for example that supposed app_server crash in the "picasso" thread (the app_server main thread). I don't know which revision this started on, but it's still a problem in hrev28327.

[korli]

Stephan, does this also happen on single cpu machines in your opinion ?

[anevilyak]

It happens on my single CPU machine at least :)

[bonefish]

To stop the speculations: gdb can only be attached to a team, and that's what the debug server does. When handing over the debugged team all threads that already caused a debug event (and are waiting for instructions from the debugger) will resend the notification messages to the new debugger. gdb will simply focus on the thread from which it gets the first message. The main problem is that gdb also enables other debug events, and that another thread could cause such a debug event quickly enough, sending its notification message earlier than any other thread, thus resulting in the input loop to be set to that thread instead of the "bad" one. Most likely this will be the main thread, since gdb also does a debug_thread() on this one (gdb doesn't know the debugged team has been handed over from the debug server, so it has to do that), but it could also be another thread that just received a signal, created a thread, loaded an add-on, etc.

Anyway while this is certainly annoying, there's also no need to guess the thread in question. A "cont" should usually switch to the right one, and in doubt a look into the syslog will bring certainty. The debug server logs which thread was the cause and also dumps a stack trace.

[bonefish]

Fixed in hrev29303.