c – 分析由于库有错误而发生的崩溃的回溯

前端之家收集整理的这篇文章主要介绍了c – 分析由于库有错误而发生的崩溃的回溯前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我的应用程序中,我有设置信号处理程序来捕获Segfaults,并打印bactraces.
进程启动时,我的应用程序会加载一些插件库.

如果我的应用程序崩溃了一个段错误,由于主可执行二进制文件中的错误,我可以用以下内容分析回溯:

addr2line -Cif -e ./myapplication 0x4...

它准确地显示函数和source_file:line_no

但是,如何分析是否由于插件中的错误而发生崩溃,如下面的回溯?

/opt/myapplication(_Z7sigsegvv+0x15)[0x504245]
/lib64/libpthread.so.0[0x3f1c40f500]
/opt/myapplication/modules/myplugin.so(_ZN11ICAPSection7processEP12CONNECTION_TP7Filebufi+0x6af)[0x7f5588fe4bbf]
/opt/myapplication/modules/myplugin.so(_Z11myplugin_reqmodP12CONNECTION_TP7Filebuf+0x68)[0x7f5588fe51e8]
/opt/myapplication(_ZN10Processors7ExecuteEiP12CONNECTION_TP7Filebuf+0x5b)[0x4e584b]
/opt/myapplication(_Z15process_requestP12CONNECTION_TP7Filebuf+0x462)[0x4efa92]
/opt/myapplication(_Z14handle_requestP12CONNECTION_T+0x1c6d)[0x4d4ded]
/opt/myapplication(_Z13process_entryP12CONNECTION_T+0x240)[0x4d79c0]
/lib64/libpthread.so.0[0x3f1c407851]
/lib64/libc.so.6(clone+0x6d)[0x3f1bce890d]

我的应用程序和插件库都使用gcc编译并且未被删除.
我的应用程序在执行时,使用dlopen加载plugin.so
不幸的是,崩溃发生在我无法在gdb下运行应用程序的站点.

谷歌疯狂地搜索答案,但所有讨论回溯和addr2line的网站排除了可能需要分析错误插件的情况.
我希望一些善良的黑客知道这个困境的解决方案,并且可以分享一些见解.对于其他程序员来说,这将是非常宝贵的.

提前谢谢.

解决方法

以下是一些可能有助于您调试此提示提示

回溯中的地址是进程崩溃时地址空间中的地址.这意味着,如果您想将其转换为相对于库的.text部分开头的“物理”地址,则必须从回溯中的地址中减去pmap相关部分的起始地址.

不幸的是,这意味着在崩溃之前需要一个流程的pmap.我承认不知道如果你关闭并重新运行它,在单个系统上加载库的地址是否是不变的(可以想象有安全功能随机化这个),但它确实不能跨系统移植,正如你已经注意到的那样.

在你的位置,我会尝试:

>使用c filt -n或手动对符号名称进行解码.我现在没有shell,所以这是我的手动尝试:_ZN11ICAPSection7processEP12CONNECTION_TP7Filebufi是ICAPSection :: process(CONNECTION_T *,Filebuf *,int).这可能已经有所帮助.如果不:>使用objdump或nm(我很确定他们可以这样做)找到与受损名称相对应的地址,然后将偏移量(对应于堆栈跟踪的0x6af)添加到此处,然后使用addr2line查找生成的地址.

猜你在找的C&C++相关文章