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

概述在我的应用程序中,我有设置信号处理程序来捕获Segfaults,并打印bactraces. 进程启动时,我的应用程序会加载一些插件库. 如果我的应用程序崩溃了一个段错误,由于主可执行二进制文件中的错误,我可以用以下内容分析回溯： addr2line -Cif -e ./myapplication 0x4... 它准确地显示了函数和source_file：line_no 但是,如何分析是否由于插件中 在我的应用程序中,我有设置信号处理程序来捕获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 – 分析由于库有错误而发生的崩溃的回溯所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。