How does gdb attach to multi-threaded process?

Question

I will try to be as specific as I can, but so far I have worded this problem so poorly that Google failed to return any useful results (hence my question here).

I am attaching gdb to a multi-threaded c++ server process. All I can say is that strange things have been happening while trying to do the usual set-breakpoint-break-investigate.

First , while waiting for the breakpoint to be hit (in 'Continuing' mode), I suddenly got back the (gdb) prompt with the message:

Continuing.
[Thread 0x54d5b940 (LWP 28503) exited]
[New Thread 0x54d5b940 (LWP 28726)]
Cannot get thread event message: debugger service failed

Second , also while waiting for the breakpoint to be hit, I'm suddenly told the program has received SIGSEGV and - back to the (gdb) prompt - backtrace tells me the segfault happened in pthread_cancel(). Note the process under investigation does not normally segfault.

I clearly lack enough information about how gdb works to even begin guessing what is happening. Am I doing anything wrong? The steps I take are the same each time:

1. gdb attach
2. break 'MyFunction()'
3. continue

Thoughts? Thanks.

Answer 1

I fought with similar gdb issues for a while. My case was having lots of threads spawned that executed few functions and then exited.

It appears if a thread exits too fast and there's lots of these happening sometimes gdb cannot keep up and when it fails, it fails with style as in crashes :) I think it tries to attach to a thread that is already done as per the error message.

I see this as an issue in gdb 6.5 to 7.6 and still happening. Did not try with older versions.

My advice is look for this use case or similar. Once I changed my design to have a thread serving a queue of requests gdb works flawlessly.

Design wise is healthier to have already created threads that digest actions than always spawning new threads.

Still same code debugs without a problem on Visual Studio so I do have to say that is a small disappointment to me with regards to gdb.

I use Eclipse and looking at the GDB traces (usually enabled by default) will give you a better hint of where GDB fails. One of the buttons on the console shows you the GDB trace.