我的程序运行过程中dump,怎么分析呢(backtrace)

发布于 2022-10-15 04:06:55 字数 2360 浏览 21 评论 0

本帖最后由 charmfish 于 2011-06-17 00:16 编辑

在gdb调试的时候backtrace用于显示堆栈,里面比较好看到大致在哪出了问题
现在问题是我在运行时dmp了,有backtrace提示,但是我不能分析具体的那个函数调用上出了问题,因为此时的输出没有函数名。
如下:
======= Backtrace: =========
/lib/libc.so.6[0x271883]
/lib/libc.so.6(__libc_malloc+0x7b)[0x2733ab]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0x1c5aa7]
/usr/lib/libstdc++.so.6(_Znaj+0x1d)[0x1c5bdd]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDFileServerCore.so.2.0[0x3e4602]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDFileServerCore.so.2.0[0x3e4673]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDFileServerCore.so.2.0[0x41f539]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDFileServerCore.so.2.0[0x4260e1]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDFileServerCore.so.2.0[0x41a74c]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDFileServerCore.so.2.0[0x3fc816]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x701554]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x7022f5]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x7120d0]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x7127e3]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x70fcbd]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x712bf4]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x710122]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x715080]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRNetBase.so.2.0(_ZN11ACE_Reactor22run_reactor_event_loopEPFiPS_E+0x52)[0xd6fd7e]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRBaseModuleEx.so.2.0[0x70e291]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRNetBase.so.2.0(_ZN18ACE_Thread_Adapter8invoke_iEv+0x81)[0xd88825]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRNetBase.so.2.0(_ZN18ACE_Thread_Adapter6invokeEv+0xb4)[0xd888e6]
/SourceCode/DR/Bin/CentOS5.3_32_Debug/libDRNetBase.so.2.0(ace_thread_adapter+0x1e)[0xcf499e]
/lib/libpthread.so.0[0x84749b]
/lib/libc.so.6(clone+0x5e)[0x2d942e]

有什么方法让运行时的backtrace更详细呢?
或者有什么方法能大致分析到类似上面的调用堆栈到底是哪个函数有问题
上面每行的最后一个地址值是啥呢? 是指令(函数)地址吗?

谢谢大家

另外一个问题,GDB调试运行时没问题,运行时有问题,这个回是啥原因,都是debug版本的

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

桜花祭 2022-10-22 04:06:55

好像 就是:分配内存malloc的时候挂了
但不能 看到 代码位置.
楼主的这个版本,好像不是debug版的啊!

gcc 编译选项是啥?

有没有:用 “-g” 参数

巨坚强 2022-10-22 04:06:55

to 楼上 : -ggdb

再说一遍:
不是调试时出的,是运行时出的

時窥 2022-10-22 04:06:55

to 楼上 : -ggdb

再说一遍:
不是调试时出的,是运行时出的
charmfish 发表于 2011-06-17 12:29

    ulimit -c unlimited

生成core文件
然后gdb -c core文件 执行的文件

出错后,直接输入bt查看就可以了

不爱素颜 2022-10-22 04:06:55

本帖最后由 bbxyard 于 2011-06-17 13:18 编辑

回复 3# charmfish
"-g" 和 "ggdb" 效果是一样的. 打出更多的调试信息可以用"-g3"(至少编译的文件)比以前大了点噢

程序挂了以后,可以用 生成的core文件来调.
先检查一下core文件是否能生成.
执行一下:

  1. ulimit -c

复制代码如果显示:“unlimited” 则会生成core文件.
否则

  1. ulimit -c unlimited

复制代码即可.

生成core之后,如下gdb即可

  1. gdb ./a.out core

复制代码和4楼的撞车了,呵呵,一个意思呵呵:emn1:

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文