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

Question

我在退出和_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中,因此没有延迟加载共享库问题.有人知道一些其他神秘的退出触发器无法捕获吗？

编辑:问题现在只是学术问题.我尝试了二进制搜索调试,退出了我的一部分更改(问题消失了).在我按顺序再次应用它们之后,即使事情恢复到原始状态,我也无法再重现问题.

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

Answer 1

_exit断点"错过" 有两个常见原因- 要么GDB没有将断点设置在正确的位置,要么程序执行(道德等同于)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将导致进程终止).

编辑:

另外值得注意的是,您可以使用助记符名称,而不是系统调用号码.您还可以同时将多个系统调用添加到catch列表中,如下所示:

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