linux - 设置 gdb 退出断点不起作用？

Question

我在 exit 和 _exit 上设置了断点，我的程序(多线程应用程序，在 linux 2.6.16.46-0.12 sles10 上运行)仍然以某种我无法找到的方式退出

(gdb) c...[New Thread 47513671297344 (LWP 15279)][New Thread 47513667103040 (LWP 15280)][New Thread 47513662908736 (LWP 15281)]Program exited with code 0177.(gdb)

退出函数驻留在 libc 中，因此不存在延迟加载共享库问题。有人知道其他一些无法捕获的神秘退出触发器吗？

编辑:现在的问题只是学术问题。我尝试了二进制搜索调试，取消了我的更改的子集(问题消失了)。再次按顺序应用后，即使恢复到原始状态，我也无法再重现问题。

EDIT2:我最近发现了这种错误的一个原因，这可能是这个问题的原始来源。由于历史原因，我们的产品使用了邪恶的链接器标志 -Bsymbolic。这样做的副作用之一是，当一个符号未定义但被调用时，GLIBC 运行时链接器将以这种方式轰炸，并且您在调试器中看到它作为进程以 0177 退出。当运行时链接器以这种方式中止时，我我猜它会直接调用 _exit(而不是使用 C 运行时库 exit() 或 _exit())。这与我无法通过调试器中的退出断点捕捉到这一点的事实是一致的。

Answer 1

_exit 断点“未命中”的常见原因有两个——GDB 没有在正确的位置设置断点，或者程序执行(a道德等同于)syscall(SYS_exit, ...)

info break 和 disassemble _exit 说了什么？

您可以说服 GDB 使用 break *&_exit 正确设置断点。或者，GDB-7.0 支持catch syscall。无论程序如何退出，这样的事情都应该有效(假设 Linux/x86_64；请注意，在 ix86 上，数字将不同):

(gdb) catch syscall 60
Catchpoint 3 (syscall 'exit' [60])
(gdb) catch syscall 231
Catchpoint 4 (syscall 'exit_group' [231])
(gdb) c

Catchpoint 4 (call to syscall 'exit_group'), 0x00007ffff7912f3d in _exit () from /lib/libc.so.6

更新:
您的评论表明 _exit 断点设置正确，因此您的进程很可能只是不执行 _exit。

剩下 syscall(SYS_exit, ...) 和另一种可能性(我之前错过了):所有线程都执行 pthread_exit。您可能还想在 pthread_exit 上设置一个断点(并在每次点击它时执行 info thread -- 最后一个执行 pthread_exit 的线程将导致进程终止)。

编辑:

还值得注意的是，您可以使用助记名称，而不是系统调用编号。您还可以像这样同时将多个系统调用添加到捕获列表:

(gdb) catch syscall exit exit_group
Catchpoint 2 (syscalls 'exit' [1] 'exit_group' [252])