为什么gdb会挂起？
我正在调试一个应用程序，我试图了解 gdb 的工作原理以及为什么我有时无法单步调试该应用程序。我遇到的问题是，当我单步执行程序时，gdb 将挂起，并且它所附加的进程将进入失效状态。 gdb 挂起后，我必须杀死它以释放终端（ctrl-C 不起作用，我必须通过获取该 gdb 会话的进程 ID 并使用kill -9 从不同的终端窗口执行此操作）。
我猜测 gdb 挂起是因为它正在等待应用程序在下一条指令处停止，并且不知何故应用程序完成执行而 gdb 没有识别这一点。但这只是我根据迄今为止观察到的行为进行的猜测。所以我的问题是是否有人以前见过这种类型的行为和/或可以建议可能的原因是什么。我认为这可能会帮助我改进我的调试策略。
如果重要的话，我正在使用 g++ 4.4.3、gdb 7.1，在 Ubuntu 10.04 x86_64 上运行。
I have an application that I am debugging and I'm trying to understand how gdb works and why I am not able to step through the application sometimes. The problem that I am experiencing is that gdb will hang and the process it is attached to will enter a defunct state when I am stepping through the program. After gdb hangs and I have to kill it to free the terminal (ctrl-C does not work, I have to do this from a different terminal window by getting the process id for that gdb session and using kill -9).
I'm guessing that gdb is hanging because it's waiting for the application to stop at the next instruction and somehow the application finished execution without gdb identifying this. But that's just speculation on my part from the behavior I've observed thus far. So my question is if anyone has seen this type of behavior before and/or could suggest what the cause might be. I think that might help me improve my debugging strategy.
In case it matters I'm using g++ 4.4.3, gdb 7.1, running on Ubuntu 10.04 x86_64.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我遇到了类似的问题，并通过向正在调试的进程发送
CONT信号来解决它。I had a similar problem and solved it by sending a
CONTsignal to the process being debugged.我想说，如果它是挂起的原因，则调试的进程不会闲置。每次 GDB 完成一个步骤时，它都必须更新您需要打印的任何表达式。它可能包括以下指针，因此在某些情况下，它可能会失败（尽管我不记得真正的“挂起”）。它通常还会尝试更新您的堆栈跟踪。如果堆栈跟踪已损坏并且不再连贯，则可能会陷入无限循环。将 gdb 附加到
strace以查看挂起期间发生的活动类型可能是进一步找出问题的好方法。（例如，通过不再工作的 NFS/SSHFS 挂载访问源是 gdb 挂起的最常见原因之一，此处：P）
I'd say the debugged process wouldn't sit idle if it was the cause of the hang. Every time GDB has completed a step, it has to update any expressions you required to print. It may include following pointers and so, and in some case, it may fail there (although I don't remind of a real "hang"). It also typically try to update your stack trace. If the stack trace has been corrupted and is no longer coherent, it could be trapped into an endless loop. Attaching gdb to
straceto see what kind of activity is going on during the hang could be a good way to go one step further into figuring out the problem.(e.g. accessing sources through a no-longer-working NFS/SSHFS mount is one of the most frequent reason for gdb to hang, here :P)