用gdb调试core dump文件

gdb基本的使用方法在此就不说了。

载入core文件的命令行为:

dgb exe core

例如

gdb ./testall ./core.2345

最重要的一个命令是where,这个就像windbg的命令 !analyze -v

我模拟了几个crash的情况,一个一个说。

第一个:删除两次指针导致crash的情况

源程序

char *a = new char[2];

delete []a;

delete []a;

运行时

*** glibc detected *** ./testall: double free or corruption (fasttop): 0x09d7e008 ***

======= Backtrace: =========

/lib/libc.so.6[0x1a6d35]

/lib/libc.so.6(cfree+0x59)[0x1aad29]

/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x683f5c1]

/usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0x683f61d]

./testall[0x804a518]

./testall[0x804a242]

./testall[0x80493e4]

./testall[0x80495e0]

./testall(__gxx_personality_v0+0x19f)[0x804906b]

/lib/libc.so.6(__libc_start_main+0xdc)[0x152ebc]

./testall(__gxx_personality_v0+0xb5)[0x8048f81]

======= Memory map: ========

0013d000-00294000 r-xp 00000000 fd:00 12815259   /lib/libc-2.5.so

00294000-00296000 r-xp 00157000 fd:00 12815259   /lib/libc-2.5.so

00296000-00297000 rwxp 00159000 fd:00 12815259   /lib/libc-2.5.so

00297000-0029a000 rwxp 00297000 00:00 0

0089a000-008a5000 r-xp 00000000 fd:00 12815281   /lib/libgcc_s-4.1.2-20080825.so.1

008a5000-008a6000 rwxp 0000a000 fd:00 12815281   /lib/libgcc_s-4.1.2-20080825.so.1

00b52000-00b6d000 r-xp 00000000 fd:00 12815258   /lib/ld-2.5.so

00b6d000-00b6e000 r-xp 0001a000 fd:00 12815258   /lib/ld-2.5.so

00b6e000-00b6f000 rwxp 0001b000 fd:00 12815258   /lib/ld-2.5.so

00b94000-00b95000 r-xp 00b94000 00:00 0          [vdso]

00cd0000-00cf7000 r-xp 00000000 fd:00 12815266   /lib/libm-2.5.so

00cf7000-00cf8000 r-xp 00026000 fd:00 12815266   /lib/libm-2.5.so

00cf8000-00cf9000 rwxp 00027000 fd:00 12815266   /lib/libm-2.5.so

00d17000-00d2d000 r-xp 00000000 fd:00 12815261   /lib/libpthread-2.5.so

00d2d000-00d2e000 r-xp 00015000 fd:00 12815261   /lib/libpthread-2.5.so

00d2e000-00d2f000 rwxp 00016000 fd:00 12815261   /lib/libpthread-2.5.so

00d2f000-00d31000 rwxp 00d2f000 00:00 0

0678c000-0686c000 r-xp 00000000 fd:00 12690777   /usr/lib/libstdc++.so.6.0.8

0686c000-06870000 r-xp 000df000 fd:00 12690777   /usr/lib/libstdc++.so.6.0.8

06870000-06871000 rwxp 000e3000 fd:00 12690777   /usr/lib/libstdc++.so.6.0.8

06871000-06877000 rwxp 06871000 00:00 0

08048000-0804e000 r-xp 00000000 fd:00 6127658    /home/zhaha05/test/testall/testall

0804e000-0804f000 rw-p 00005000 fd:00 6127658    /home/zhaha05/test/testall/testall

09d7e000-09d9f000 rw-p 09d7e000 00:00 0          [heap]

b7f36000-b7f38000 rw-p b7f36000 00:00 0

b7f48000-b7f4b000 rw-p b7f48000 00:00 0

bf8da000-bf8ef000 rw-p bffe9000 00:00 0          [stack]

Aborted (core dumped)

gdb调试core文件时

gdb testall core.8812

GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-45.el5)

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "i386-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /home/zhaha05/test/testall/testall...done.

[New Thread 8812]

warning: .dynamic section for "/lib/libc.so.6" is not at the expected address

warning: difference appears to be caused by prelink, adjusting expectations

Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.

[Thread debugging using libthread_db enabled]

Loaded symbols for /lib/libpthread.so.0

Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done.

Loaded symbols for /usr/lib/libstdc++.so.6

Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.

Loaded symbols for /lib/libm.so.6

Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.

Loaded symbols for /lib/libgcc_s.so.1

Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.

Loaded symbols for /lib/libc.so.6

Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.

Loaded symbols for /lib/ld-linux.so.2

Core was generated by `./testall‘.

Program terminated with signal 6, Aborted.

#0  0x00b94402 in __kernel_vsyscall ()

(gdb) where

#0  0x00b94402 in __kernel_vsyscall ()

#1  0x00165e30 in raise () from /lib/libc.so.6

#2  0x00167741 in abort () from /lib/libc.so.6

#3  0x0019e99b in __libc_message () from /lib/libc.so.6

#4  0x001a6d35 in _int_free () from /lib/libc.so.6

#5  0x001aad29 in free () from /lib/libc.so.6

#6  0x0683f5c1 in operator delete(void*) () from /usr/lib/libstdc++.so.6

#7  0x0683f61d in operator delete[](void*) () from /usr/lib/libstdc++.so.6

#8  0x0804a518 in FILE_OPEN_rha_test_c::TestMethod (this=0x9d7e108, parser=...)

at file.cpp:25

#9  0x0804a242 in rha_test_case_c::run_command (command=0x9d7e2cc "FILE.OPEN",

parser=...) at shell_test.h:194

#10 0x080493e4 in shell_test_c::execute_command (

cmd=0xbf8ecc94 "FILE.OPEN t.txt") at shell_test.cpp:68

#11 0x080495e0 in shell_test_c::go (this=0xbf8ed4cc, argc=1, argv=0xbf8ed574)

at shell_test.cpp:107

#12 0x0804906b in main (argc=1, argv=0xbf8ed574) at main.cpp:7

(gdb)

第二个:空指针

源程序

char *nullpointer = NULL;

strcpy(nullpointer,"12334567890");

运行时

Segmentation fault (core dumped)

gdb调试时

Program terminated with signal 11, Segmentation fault.

#0  0x0804a48e in FILE_OPEN_rha_test_c::TestMethod (this=0x84e1108, parser=...)

at file.cpp:23

23              strcpy(nullpointer,"12334567890");

第三个:buffer overflow

源程序

char overflow[1];

strcpy(overflow,"1234567890");

运行时

Segmentation fault

gdb调试时

Program terminated with signal 11, Segmentation fault.

#0  0x0683a919 in __gnu_cxx::__exchange_and_add(int volatile*, int) ()

from /usr/lib/libstdc++.so.6

(gdb) where

#0  0x0683a919 in __gnu_cxx::__exchange_and_add(int volatile*, int) ()

from /usr/lib/libstdc++.so.6

#1  0x0681ed24 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /usr/lib/libstdc++.so.6

#2  0x0804a4d1 in FILE_OPEN_rha_test_c::TestMethod (this=0x8e7f108, parser=...)

at file.cpp:24

#3  0x0804a1e2 in rha_test_case_c::run_command (command=0x8e7f2cc "FILE.OPEN",

parser=...) at shell_test.h:194

#4  0x08049384 in shell_test_c::execute_command (

cmd=0xbff0bd54 "FILE.OPEN t.txt") at shell_test.cpp:68

#5  0x08049580 in shell_test_c::go (this=0xbff0c58c, argc=1, argv=0xbff0c634)

at shell_test.cpp:107

#6  0x0804900b in main (argc=1, argv=0xbff0c634) at main.cpp:7



时间: 2024-10-06 16:34:36

用gdb调试core dump文件的相关文章

GDB调试core dump文件示例

上篇论述了三层的基本概念,作用,关系,现在展示下系统中用户登陆过程中简单应用三层结构设计思想. vb.NET的操作如下 首先建立以下windows应用程序以及类库 首先建立实体类 Public Class userInfo Private _username As String Public Property UserName As String Get Return _username End Get Set(ByVal value As String) _username = value E

[笔记]用gdb调试core dump

总是隔一段时间才写一次C++,有些东西老是用完就忘了……记一下如何用gdb来调试core dump免得到时候又忘记. 首先需要设置core file的大小,默认是0所以不设不会生成core file $ ulimit -c unlimited 然后在编译的flag里加上 -g -rdynamic 把动态静态符号表都弄过来 然后 $ make $ # 干点啥让它core dump 假设可执行文件叫test,生成的core file叫core(ubuntu 12.04是的,其他系统可能叫其他名字)

Unix 用gdb分析core dump文件

产生core文件条件 用ulimit -c 指定core文件大小来开启core文件的生成,如:ulimit -c unlimited 用gdb分析core文件的条件 可执行程序在编译时,需加入-g参数,否则gdb无法找到symbol信息,从而无法定位问题. 例如,如下两个cpp文件中,test.cpp会导致crash. // test.cpp void testCrash() { int *p = 0; *p = 3; } // main.cpp #include <stdio.h> void

gdb调试常用实用命令和core dump文件的生成(转)

1.生成core dump文件的方法: $  ulimit -c //查看是否为0 如果为0 $   ulimit -c unlimited 这样在程序崩溃以后会在当前目录生成一个core.xxxx的文件 2.调试core dump文件 生成了core.xxx文件以后 $  gdb ./应用程序  core.xxxx 就会恢复现场到你的程序崩溃的那一刻 (gdb)bt          //这个命令会列出程序崩溃时的堆栈信息,一层一层会有标号  #0  #1  #2 ....... 如果你要查看

gdb调试core文件

什么是Core Dump?Core的意思是内存, Dump的意思是扔出来, 堆出来.开发和使用Unix程序时, 有时程序莫名其妙的down了, 却没有任何的提示(有时候会提示core dumped). 这时候可以查看一下有没有形如core.进程号的文件生成, 这个文件便是操作系统把程序down掉时的内存内容扔出来生成的, 它可以做为调试程序的参考.core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core

段错误Segment Fault定位,即core dump文件与gdb定位

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设

【Z】段错误Segment Fault定位,即core dump文件与gdb定位

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设

Ubuntu16.04下写的Qt程序,调试时没问题,运行时偶现崩溃 (需要在运行时生成core dump文件,QMAKE_CC += -g)

记录一下 Ubuntu16.04下写的Qt程序,调试时没问题,运行时偶现崩溃 需要在运行时生成core dump文件 首先在pro结尾里加入 QMAKE_CC += -g QMAKE_CXX += -g QMAKE_LINK += -g 在终端输入 ulimit -c 显示为 0 然后输入 ulimit -c unlimited 继续在终端运行编写的程序 出错后,会在当前目录生成 core 文件 然后在终端执行 “gdb 你的程序名 core” 然后输入 bt 对该错误进行跟踪调试 (gdb)

Linux下交叉编译gdb,gdbserver+gdb的使用以及通过gdb调试core文件

交叉编译gdb和gdbserver 1.下载gdb:下载地址为:http://ftp.gnu.org/gnu/gdb/按照一般的想法,最新版本越好,因此下载7.2这个版本.当然,凡事无绝对.我们以gdb-7.2.tar.bz2 这个文件为例.2.解压缩: $ tar jxvf gdb-7.2.tar.bz2 注:小技巧:Linux下一般压缩文件后缀为.tar.bz2和.tar.gz,它们解压命令有两三个选项是一致的: xf(v),前者再加上j选项,后者再加上z选项. 3.进入该目录 $ cd g