我会尝试尽可能具体，但到目前为止，我已经把这个问题措辞得很糟糕以至于谷歌没有返回任何有用的结果（因此我的问题在这里）。
我将gdb附加到多线程c ++服务器进程。我只能说，在尝试进行通常的set-breakpoint-break-investigation时，发生了奇怪的事情。
第一次，在等待断点被点击时（在“继续”模式下），我突然收到了（gdb）提示，并显示以下消息：
Continuing. [Thread 0x54d5b940 (LWP 28503) exited] [New Thread 0x54d5b940 (LWP 28726)] Cannot get thread event message: debugger service failed
第二次，同时在等待断点被击中时，我突然告诉程序已收到SIGSEGV并且 - 回到（gdb）提示符 - backtrace告诉我在pthread_cancel中发生了段错误（）。请注意，调查过程通常不会发生段错误。
我显然缺乏足够的信息，关于gdb如何工作甚至开始猜测发生了什么。我做错了吗？我每次采取的步骤都是相同的：
思考？感谢。
答案 0 :(得分：4)
我和类似的gdb问题争吵了一段时间。我的情况是产生了许多执行少量功能然后退出的线程。
如果一个线程退出太快并且有很多这样的事情发生，有时gdb无法跟上并且当它失败时，它会失败，因为崩溃中的样式:)我认为它试图附加到已经完成的线程根据错误消息。
我认为这是gdb 6.5到7.6中的问题并且仍在发生。没试过旧版本。
我的建议是查找此用例或类似用例。一旦我改变了我的设计，让一个线程服务于一个请求队列，gdb就可以完美地运行。
设计智能已经创建了消化动作的线程，而不是总是产生新线程。
仍然相同的代码在Visual Studio上没有问题进行调试，所以我不得不说对于gdb来说这是一个小小的失望。
我使用Eclipse并查看GDB跟踪（通常默认启用）将为您提供更好的GDB失败位置的提示。控制台上的一个按钮显示GDB跟踪。