How does gdb attach to multi-threaded process?

3
votes

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.

1
c++multithreadinggdb
I take it this is Linux? As far as I understand, it attaches to the PROCESS, which may have one or more threads. - Mats Petersson
Yes, sorry, Red Hat Emterprise Linux release 5.4 (Tikanga). Yes, it does attach to the process and the process does have multiple threads. - Maria Boghiu
For your second problem: Running under a debugger usually changes the timing of threads because of the debugger overhead. This can trigger existing bugs, which are very unlikely to be observed otherwise. - languitar
Uh very good point. Thanks. - Maria Boghiu

1 Answers

4
votes

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.