程序死了,gdb看了一下gdb生成core文件件,发现都是问号。

gdb 的一些常用命令, 及在程序发生段错误后如何通过调试 core dump 迅速定位到出错位置.
不罗列一大堆命令了, 只是把碰到的/用过的整理一下, 以后再使用到新的命令, 再补充. 有几篇总结的比较好的文章可以参考: 、、
1. 添加调试信息
为了能使用 gdb 进行调试, 需要添加 -g 选项添加调试信息.
g++ -g test.cpp -o test
2. 常用命令
使用 gdb test 即可以进入调试程序, 以下列出几个常用命 令.
显示图形化代码 Ctrl+x+a
启动程序 r (run)
断点 b (breakpoint)
清除/禁用/启用断点 delete/disable/enable
单步 s (step 碰到函数会进入)
单行 n (next 碰到函数不会进行, 而是整条执行)
执行到下一个断点 c (continue)
查看变量 p (print)
显示变量 display
查看当前调用堆栈 bt (backtrace)
查看某一层调用代码 f (frame)
3. 调试 core dump
程序执行时, 经常会因为段错误(Segment Fault)而退出, 操作系统会把此程序当前内存信息 dump 到磁盘上(详见 wiki), 即生成 core 文件. 对 core 进行分析可以很快分析出导致程序 crash 的地方.
(1). 设置 core 文件大小
系统默认不会生成 core 文件, 需要进一步设置. core 文件的生成依赖于 shell 的设置, 在 shell 中运行命令: ulimit -a, 从第一行的设置项可以看到系统设置的 core file size 为 0, 即不生成 core file.
使用命令: ulimit -c unlimited 可以设置 core file size 为无限.
(2). 生成简单 core 文件
在 C++ 中制造一个 segment falt 太容易了, 直接给一个空指针赋值就可以了.
int main(int argc, char const *argv[])
*p = ‘a’;
保存文件为 coreDumpTest.cpp, 编译并运行, 即可以现磁盘上多了一个 core 文件, 就是这个程序发生段错误 dump 下来的进程信息.
(3). 调试简单 core 文件
使用 gdb ./coreDumpTest core 来调试 core, 发现 gdb 直接就定位到了出错的语句(第4行赋值语句), 还可以通过 print 来查看当前上下文变量, 如指针 p 的值为 nullptr.
(4). 生成稍复杂 core 文件
上面的例子太简单了, 下面通过一个稍微复杂的例子来介绍一下 gdb 中命令 backtrace 和 frame 的使用. 下面代码很简单, 就是越界访问, 用 vector 是为了体现调用层次…
#include &vector&
int main(int argc, char const *argv[])
vector&int&
vector&int&
b.push_back(a[0]);
(5). 调试稍复杂 core 文件
编译运行程序, 生成 core 文件, 使用 gdb 来调试 core, 可以看到此时直接定位到的地方是库函数中的某一行;
库函数都是经过千锤百炼, 基本不可能出错, 所以我们先从自己的程序找起. 这时我们需要知道的是代码是从哪条语句执行到这里的, 使用 backtrace(或者 where) 命令列出当前调用堆栈, 再使用 frame n 命令列出第 n 层堆栈的信息, 就可以直接看到出错的代码语句了, 接下来就是进一步分析了.
4. 简化版步骤
(1). 首先利用file core.19344命令可以得到
core.19344: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from ‘cmm_test_tool’
可以看出core.19344是由cmm_test_tool这个工程产生。
(2). 接着就可以利用命令gdb进行查找,格式为gdb 工程名 core文件名,例如 gdb cmm_test_tool core.19344
(3). 最后一个步骤是输入where,找到错误发生的位置和堆栈,如下:
(gdb) where
#0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6
#1 0× in strtoul () from /lib/i686/libc.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2, max_id=0×806fd20) at cmm_test_tool.c:788
#3 0× in ConstrctVODProgram (vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0× in TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0× in pthread_start_thread () from /lib/i686/libpthread.so.0 (gdb)
至此,可以看出文件出错的位置是函数 GetMaxIDFromDB ,两个参数分别是2和0×806fd20,这个函数位于源代码的788行,基于此,我们就可以有针对性的找到问题的根源,并加以解决。
4. 待添加:
设置 core file size 在所有 shell 都生效, 不要每次打开一个 shell 就要设置一下.
1.core文件的生成开关和大小限制
---------------------------------
1)使用ulimit
-c命令可查看core文件的生成开关。若结果为0,则表示关闭了此功能,不...
问题描述:已经在编译选项中加入了-g,但是查看core文件时,还是一堆问号,使用的命令为:gdb -c core...
最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是著名的“段错误”(Segmentation Fa...
1.core文件当程序运行过程中出现Segmentation fault (core dumped)错误时,程序停止运行,并产生core文件。core文件是程序运行状态的内存映象。使用gdb调试cor...
在linux下程序崩溃时,一般会在指定目录下生成一个core文件。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的,接下来我们通过一个案例观察怎么利用GDB调试core文件。在命令...
编写服务器端程序,很容易遇到Crash问题,比较幸运的是Linux提供了core file,保留了Crash的现场。有时候,根据当前的调用栈,并且打印出当前栈的变量就可以分析出crash的原因,但是,...
上一篇博客里我们通过3个例子介绍了gdb调试coredump的时候,比较常用到的一些命令和定位方法。这篇内容里,我们将尝试去探讨gdb调试coredump的原理,以及它们背后的一些东西。
最近PHP写的web项目爆出很多core文件,不知道什么原因。百了个度说是可以用GDB调试工具查看core中的信息定位问题。
1、安装GDB
yum install gdb
2、安装debu...
一,什么是coredump
我们经常听到大家说到程序core掉了,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条...
摘要gdb 的一些常用命令, 及在程序发生段错误后如何通过调试 core dump 迅速定位到出错位置.不罗列一大堆命令了, 只是把碰到的/用过的整理一下, 以后再使用到新的命令, 再补充. 有几篇总...
没有更多推荐了,&nbsp>&nbsp
&nbsp>&nbsp
&nbsp>&nbsp
解决gdb 调试 core 文件函数名显示为问号的问题
摘要:关于gdb调试core文件总是一堆问号的问题问题描述:已经在编译选项中加入了-g,但是查看core文件时,还是一堆问号,使用的命令为:gdb-ccore解决方案:由于gdb-ccore这样的使用在有些系统下支持不是很好,所以推荐用如下两种方法:1)gdbexe(gdb)core-filecore2)gdb-ccore(gdb)fileexe
关于gdb调试core文件总是一堆问号的问题
问题描述:已经在编译选项中加入了-g,但是查看core文件时,还是一堆问号,使用的命令为:gdb -c core
解决方案:由于gdb -c core这样的使用在有些系统下支持不是很好,所以推荐用如下两种方法:
1) gdb exe
(gdb) core-file core
2) gdb -c core
(gdb) file exe
以上是的内容,更多
的内容,请您使用右上方搜索功能获取相关信息。
若你要投稿、删除文章请联系邮箱:zixun-group@service.aliyun.com,工作人员会在五个工作日内给你回复。
新用户大礼包!
现在注册,免费体验40+云产品,及域名优惠!
云服务器 ECS
可弹性伸缩、安全稳定、简单易用
&40.8元/月起
预测未发生的攻击
&24元/月起
你可能还喜欢
你可能感兴趣
阿里云教程中心为您免费提供
解决gdb 调试 core 文件函数名显示为问号的问题相关信息,包括
的信息,所有解决gdb 调试 core 文件函数名显示为问号的问题相关内容均不代表阿里云的意见!投稿删除文章请联系邮箱:zixun-group@service.aliyun.com,工作人员会在五个工作日内答复
售前咨询热线
支持与服务
资源和社区
关注阿里云
Internationalhttp://www.csdn123.com/html/mycsdn/b8d4fe782b16f3a0823c.html
程序发生Crash时,一般会coredump出转储文件core file。Crash调查的最直接目标是根据core file进行栈回溯或还原栈帧, 即find call trace。同时根据寄存器和出错处汇编代码,分析Crash的深层次原因,并提出解决方法。
coredump设置
要使coredump时产生合适的core file,需正确设置corefile format,这个在procfs中可以定制:/proc/sys/kernel/core_pattern
core_pattern包含全路径,比如是/var/core/%e-%p-%t,则表示:/var/core/进程名-进程PID-CrashTime
顺便关注一下内核源码中,core file及其名字的生成过程:do_signal
# arch/x86/kernel/signal.c-&
get_signal_to_deliver
# kernel/signal.c-&
do_coredump-&
format_corename
# fs/exec.c
为了使生成的core file发挥更为直观的作用,要注意编译exec file(executed-file)时加上-g选项,这样通过gdb工具查找到的信息才更有价值。关于core file和exec file,有几个注意点。
MUST have exec file together, the unstripMUST have shared lib file together, ifMUST accordant with core file and exec file!
如果做到了上面说的几点,发生coredump时能保留现场环境,那么正常情况下gdb的backtrace命令就能找到call trace。也就不用下面那么费劲。
但总会出现一些不好处理的异常情况。比如在x86结构CPU的程序crash时,也许会出现一堆问号,如下所示:(gdb) bt#0
0xb5ff6106 in raise () from /lib/libc.so.6#1
0xb6112ff4 in ?? () from /lib/libc.so.6#2
0xb459f900 in ?? ()#3
0xbfed551c in ?? ()#4
0xb5ff7be1 in abort () from /lib/libc.so.6#5
0x in ?? ()Previous frame inner to this frame (corrupt stack?)
出现异常的可能原因是exec file的symbol不存在或不匹配。根据之前对x86栈帧布局图的分析(),bp-ra(即栈帧基址-返回地址)必定在栈帧顶端的固定位置,可以利用这个分布特点进行栈回溯。从当前的bp0开始,找到上一个bp1=*bp0,ra1=*(bp0
+ 4),ra1就是调用函数的地址。继续回溯,bp2=*bp1,ra2=*(bp1 + 4),ra2应该是再上一级调用函数的地址。如此循环,同时用info symbol $ra* 打印出来每一级函数,就找到实际的call trace信息了。
栈回溯示例
获取pc(即eip)和bp(即ebp)的值,为回溯第一步作准备。执行gdb命令info register:(gdb) i reax
0x3e4a 15946edx
0x3e4a 15946esp
0xbfed53f8
0xbfed53f8ebp
0xbfed5400 0xbfed5400esi
0xbfed54a0 -edi
0xb5ff6206 0xb5ff6206 &raise+70&eflags
0x202 [ IF ]cs
0x73 115ss
0x7b 123ds
0x7b 123es
0x7b 123fs
实现上述栈回溯的shell脚本代码关键部分如下:
echo "Call func is: "
info symbol $pc
#打印当前函数的符号(即名字)
#显示上一个栈帧顶部4个内存地址中的值,首先是上一个栈帧的bp和调用函数ra。保存在文件calltrace.log中最后一行
#下面是循环迭代部分
bp_now=$(tail -l "calltrace.log" | awk -F: '{print$1}')
#当前栈帧基址
bp_up=$(tail -l "calltrace.log" | awk '{print$2}')
#上一个栈帧基址
func_up=$(tail -l "calltrace.log" | awk '{print$3}')
#上一个栈帧对应函数
if [ $bp_up = "Cannot" -o $bp_up = "can't" ]; then
gdb -q "$exec_file" "$core_file" && EOF
set loggint redirect on
set prompt
set logging file "calltrace.log"
set height 0
echo Call function in:
print/x $func_up
info symbol $func_up
#打印上一个栈帧对应函数的符号(即名字),形成call trace!
echo Upper frame bp is:
print/x $bp_up
x/4x $bp_up
#为下一次回溯作准备!
一次回溯的打印结果如下所示:Call func is: raise + 70 in section .text
#当前函数0xbfed5400:
0xbfed552c
0xb5ff7bd1
0xxbfed54a0
Call function in:$1 = 0xb5ff7bd1abort + 257 in section .text
#上一个调用函数Upper frame bp is:$2 = 0xbfed552c0xbfed552c:
0xbfed5b78
0xb602f2ab
0xxbfed5664
x86的backtrace异常还有一种情况是只能回溯一二级栈帧,如下所示:
(gdb) bt#0
0xb5ff6106 in raise () from /lib/libc.so.6(gdb) x $ebp0x0:
Cannot acess memory at adderss 0x0
这种情况一般是因为栈溢出,最外层的部分栈帧被冲掉了,所以无法进行栈回溯。这时,还是可以利用bp-ra在固定位置的分布特点来调查,从当前sp开始找“栈地址-函数地址”对,找到后就开始按上面的方法回溯。
PowerPC和ARM的栈回溯
鉴于PowerPC和ARM结构的CPU也有类似的栈帧布局,也可以采用上面的方法解决backtrace异常的问题。PowerPC栈帧布局特点见 ,ARM栈帧布局特点见 。由于暂时没有target环境,也未找到合适的虚拟硬件场景技术,所以无法为PowerPC和ARM类型的CPU程序Crash调查提供栈回溯例子,以后有机会补上。
gdb 0x in ?? () 错误处理
[clug] gdb output
Duncan Roe duncan_roe
at acslink.net.au
Mon Mar 8 04:15:56 GMT 2004
Previous me...
解决gdb 调试 core 文件函数名显示为问号的问题
问题描述:已经在编译选项中加入了-g,但是查看core文件时,还是一堆问号,使用的命令为:gdb -c core...
gdb调试coredump(原理篇)
上一篇博客里我们通过3个例子介绍了gdb调试coredump的时候,比较常用到的一些命令和定位方法。这篇内容里,我们将尝试去探讨gdb调试coredump的原理,以及它们背后的一些东西。
gdb调试coredump文件,函数名称是问号
今天总算解决了一个大的bug,爽!我的程序crash,有了coredump文件,在Linux PC上用arm-linux-gdb debug it. The result is:#0
0x4022b...
em.query(&select 员工号,姓名,性别,职位 from 人事资料 where 1=?&, paras);请注意上面这条语句外表看上去是什么错误也没有,但是系统已运行,报空指针的错误,害得...
GDB core 问号
http://www.csdn123.com/html/mycsdn/b8d4fe782b16f3a0823c.html
程序发生Crash时,一般会c...
Android——coredump解析
coredump文件生成前文Android——coredump 配置 记录了android平台上的环境配置,生成方式 正常即为process触发那几种signal 手动coredump状态:
用 C/C++ 编写的程序, 如果遇到 Segmentation Fault 则可以通过生成 coredump 来进行调试, 根据记录的信息定位到出错代码行. 但很多时候可能用 gdb 打开 core...
1.什么是coredump?
没有更多推荐了,Erlang VM coredump gdb显示一堆问号问题 - 为程序员服务
Erlang VM coredump gdb显示一堆问号问题
信息如下:
#0 0x00a28 in ?? ()
#1 0x0000000dfcbeac18 in ?? ()
#2 0x0014 in ?? ()
#3 0x00002f in ?? ()
#4 0x00007fd2fcbeae30 in ?? ()
#5 0xfcbeac10 in ?? ()
#6 0x0bf50 in ?? ()
#7 0xf7b4d8 in ?? ()
#8 0x0000 in ?? ()
遇到这个问题,通常两个原因
1. core-dump产生时的程序同gdb环境下的程序不同版本,同步erlang版本即可
2. 数据写越界了(主要检查你的数组操作代码)
Erlang|LAMP|服务端架构|分布式|游戏开发
原文地址:, 感谢原作者分享。
您可能感兴趣的代码原创地址&http://blog.csdn.net/yudingding6197/article/details/5528989
我的程序crash,有了coredump文件,在Linux PC上用arm-linux-gdb debug it. The result is:
#0& 0x in ?? ()(gdb) bt#0& 0x in ?? ()#1& 0x in ?? ()#2& 0x in ?? ()Backtrace stopped: previous frame identical to this frame (corrupt stack?)(gdb)why? I can't locate the correct location, find the really reason.
看看加载的内容
GNU gdb 6.6Copyright (C) 2006 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.There is absolutely no warranty for GDB.& Type "show warranty" for details.This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux"...warning: core file may not match specified executable file.warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address (wrong library or version mismatch?)warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?)Error while mapping shared library sections:/lib/libstdc++.so.6: No such file or directory.warning: .dynamic section for "/lib/libm.so.6" is not at the expected address (wrong library or version mismatch?)warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?)warning: .dynamic section for "/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)warning: .dynamic section for "/lib/ld-linux.so.2" is not at the expected address (wrong library or version mismatch?)warning: .dynamic section for "/lib/libnss_files.so.2" is not at the expected address (wrong library or version mismatch?)Reading symbols from /lib/libdl.so.2...done.Loaded symbols for /lib/libdl.so.2Reading symbols from /lib/libpthread.so.0...done.Loaded symbols for /lib/libpthread.so.0Symbol file not found for /lib/libstdc++.so.6Reading symbols from /lib/libm.so.6...done.Loaded symbols for /lib/libm.so.6Reading symbols from /lib/libgcc_s.so.1...done.Loaded symbols for /lib/libgcc_s.so.1Reading symbols from /lib/libc.so.6...done.Loaded symbols for /lib/libc.so.6Reading symbols from /lib/ld-linux.so.2...done.Loaded symbols for /lib/ld-linux.so.2Reading symbols from /lib/libnss_files.so.2...done.Loaded symbols for /lib/libnss_files.so.2Core was generated by `./6800plusEth.bin'.Program terminated with signal 11, Segmentation fault.
一些库找不到(/lib/libstdc++.so.6),或者版本不匹配。我不应该加载/lib/libdl..so.... 这些文件,这是针对X86的。
所以两个命令至关重要:
set solib-absolute-prefix -- Set prefix for loading absolute shared library symbol filesset solib-search-path -- Set the search path for loading non-absolute shared library symbol files
比如:set solib-... /usr/local/arm-linux/arm-linux/lib/, 两个参数的值一样就可以了。
先启动arm-linux-gdb,设置变量以后,via core-file load core dump file to analyze it.
#set&solib-absolute-prefix "library path"
#set&solib-search-path&"library path"
#file file.debug
#core-file core.1234
但是还是不能准确定位,查询embedded linux版本:
ls -l /usr/arm-linux/gcc-3.4.1-glibc-2.3.3/arm-linux/lib/libc-2.3.3.so
Linux PC上的呢:
ll /usr/local/arm/3.4.1/arm-linux/lib/libc-2.3.2.so
原来库文件不对,一个是2.3.3,另一个是2.3.2,此时发现版本匹配是至关的重要啊!!
换了一个Linux PC,它的交叉编译环境是2.3.3
哈哈!立即定位到了错误的原因!!
本文转载自:http://blog.csdn.net/yudingding6197/article/details/5528989
人打赏支持
码字总数 17938
高级程序员
C 程序在进行中发生segment fault(core dump)错误,通常与内存操作不当有关,主要有以下几种情况: (1)数组越界。 (2)修改了只读内存。 (3)scanf("%d",n),n不是指针。 …… 1. 前言:...
工欲善其事必先利其器,如何使用调试工具gdb一步步调试nginx是了解nginx的重要手段。 ps:本文的目标人群是像我这样初接触Unix编程的同学,如果有什么地方错误请指正。 熟悉gdb的使用 这里就...
王二狗子11
一、core文件设置 1、core文件的生成开关和大小限制 (1)使用ulimit -c 查看,若为0,则表示关闭了此功能,不会生成core (2)ulimit -c filesize 限制core的大小 单位kbyte ulimit -c unl...
前面转载了一篇文章关于core文件的产生和调试使用的设置,但在使用有一些需要注意的问题,如 在什么情况 才会正确地产生core文件。 列出一些常见问题: 一,如何使用core文件 1. 使用core文件...
1. 可以用ulimit -a 查看一下栈的大小。 在内核2.6.20下, stack size 为8192 kbytes 如果这里没有限制,就栈的大小就只受内存的限制。2G是上限。 2. core 文件 开启或关闭core文件的生成 ul...
没有更多内容
加载失败,请刷新页面
完整引入 main.js中全局引入并注册 import Antd from 'ant-design-vue'import 'ant-design-vue/dist/antd.css'Vue.use(Antd) 在页面中不再需要引入注册组件,可以直接使用所有的组件 &tem...
别人说我名字很长
在管理员命令提示符下键入以下命令: ### 这条命令将扫描全部系统文件并和官方系统文件对比,扫描计算机中的不一致情况。Dism /Online /Cleanup-Image /ScanHealth### 这条命令必须...
首先,HashMap 是 Map 的一个实现类,它代表的是一种键值对的数据存储形式。Key 不允许重复出现,Value 随意。jdk 8 之前,其内部是由数组+链表来实现的,而 jdk 8 对于链表长度超过 8 的链表...
oschina130111
argparse的使用 位置参数 Python import argparseparser = argparse.ArgumentParser()parser.add_argument("username", type=str, help="set user name")args = parser.parse_args() 命令......
没有更多内容
加载失败,请刷新页面
文章删除后无法恢复,确定取消删除此文章吗?
亲,自荐的博客将通过私信方式通知管理员,优秀的博客文章审核通过后将在博客推荐列表中显示
确定推荐此文章吗?
确定推荐此博主吗?
聚合全网技术文章,根据你的阅读喜好进行个性推荐
指定官方社区
深圳市奥思网络科技有限公司版权所有}

我要回帖

更多关于 gdbcore文件 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信