Linux 为什么 gdb 会挂?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/8978777/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-06 04:11:00  来源:igfitidea点击:

Why would gdb hang?

linuxgdbg++

提问by Gabriel Southern

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).

我有一个正在调试的应用程序,我试图了解 gdb 是如何工作的,以及为什么有时我无法单步调试该应用程序。我遇到的问题是 gdb 将挂起,并且当我逐步执行程序时,它所连接的进程将进入失效状态。在 gdb 挂起后,我必须杀死它以释放终端(ctrl-C 不起作用,我必须通过获取该 gdb 会话的进程 ID 并使用 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.

我猜 gdb 正在挂起,因为它正在等待应用程序在下一条指令处停止,并且应用程序以某种方式完成了执行,而 gdb 没有识别出这一点。但这只是我目前观察到的行为的推测。所以我的问题是,是否有人以前见过这种行为和/或可以提出可能的原因。我认为这可能有助于我改进调试策略。

In case it matters I'm using g++ 4.4.3, gdb 7.1, running on Ubuntu 10.04 x86_64.

如果重要,我使用的是 g++ 4.4.3、gdb 7.1,在 Ubuntu 10.04 x86_64 上运行。

采纳答案by PypeBros

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.

如果是挂起的原因,我会说调试的进程不会闲置。每次 GDB 完成一个步骤时,它都必须更新您需要打印的任何表达式。它可能包括以下指针等,在某些情况下,它可能会在那里失败(尽管我没有提醒真正的“挂起”)。它通常还会尝试更新您的堆栈跟踪。如果堆栈跟踪已损坏并且不再连贯,则可能会陷入无限循环。附加 gdb 以strace查看挂起期间正在发生的活动类型可能是进一步找出问题的好方法。

(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)

(例如,通过不再工作的 NFS/SSHFS 挂载访问源代码是 gdb 挂起的最常见原因之一,此处:P)

回答by Micha?l Witrant

I had a similar problem and solved it by sending a CONTsignal to the process being debugged.

我遇到了类似的问题,并通过向CONT正在调试的进程发送信号来解决它。