设置一个gdb退出断点不工作?

我已经设置了退出和_exit断点和我的程序(multithreading的应用程序,在Linux 2.6.16.46-0.12 sles10上运行),以某种方式仍然以我无法find的方式退出

gdb)c
 ...
 [新主题47513671297344(LWP 15279)]
 [新主题47513667103040(LWP 15280)]
 [新主题47513662908736(LWP 15281)]

程序退出代码0177。
 (GDB)

退出函数驻留在libc中,因此不存在延迟加载共享库问题。 有人知道一些其他神秘的触发因素,不能被抓住吗?

编辑:问题现在只是学术。 我尝试二进制searchdebugging,支持我的更改的一个子集(问题消失了)。 再次依次施用后,即使事情恢复到原状,我也不能再复制这个问题。

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

Solutions Collecting From Web of "设置一个gdb退出断点不工作?"

_exit断点有两个常见的原因是“错过” – 或者GDB没有在正确的位置设置断点,或者程序执行了( syscall(SYS_exit, ...)的道德等价物syscall(SYS_exit, ...)

什么info breakdisassemble _exit说?

你可以说服GDBbreak *&_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]) 

在_exit上设置断点是个好主意。

你也可以尝试链接静态,只是为了从桌面上一堆潜在的gdb复杂性。

0177是可疑的等待状态 wait(2)返回儿童停止 ,但gdb打印退出状态 ,这是不同的事情,所以这可能是一个真正的退出参数。

这可能是你有一些懒惰的引用未解决在一些共享库加载到进程中。 我有完全一样的情况,“有人在某处”退出过程,似乎是没有解决的参考。

用“ldd -r”选项检查你的进程。

看起来像ld.so或任何懒惰解决一些符号统一出口功能(这应该是中止恕我直言)。

我的情况:

 $ ldd ./program undefined symbol: XXXX (/usr/lib/libYYY.so) $./program program: started! ... <program is running regardless of undefined references> 

现在退出时,我已经调用了一些使用未定义函数的场景。 它总是退出exitcode = 127和gdb报告0177。