让程序崩溃时产生coredump

最新推荐文章于 2022-09-02 07:11:33 发布

jfkidear

最新推荐文章于 2022-09-02 07:11:33 发布

阅读量1k

点赞数

分类专栏： Linux 文章标签： debugging file signal 2010 汇编 windows

Linux 专栏收录该内容

250 篇文章 0 订阅

订阅专栏

让程序崩溃时产生coredump

分类：程序调试 c&c++语言 2011-07-25 22:40 119人阅读评论(0) 收藏举报

Core Dump

[ 2010-01-06 13:38:30 | 作者: yuhen ]

在 Windows 下我们已经习惯了用 Windbg 之类的工具调试 dump 文件，从而分析并排除程序运行时错误。在 Linux 下我们同样可以完成类似的工作 —— Core Dump。

我们先看看相关的设置。

$ ulimit -a

core file size       (blocks, -c) 0
data seg size        (kbytes, -d) unlimited
scheduling priority          (-e) 20
file size            (blocks, -f) unlimited
pending signals              (-i) 16382
max locked memory    (kbytes, -l) 64
max memory size      (kbytes, -m) unlimited
open files                   (-n) 1024
pipe size         (512 bytes, -p) 8
POSIX message queues  (bytes, -q) 819200
real-time priority           (-r) 0
stack size           (kbytes, -s) 8192
cpu time            (seconds, -t) unlimited
max user processes           (-u) unlimited
virtual memory       (kbytes, -v) unlimited
file locks                   (-x) unlimited

"core file size (blocks, -c) 0" 意味着在程序崩溃时不会生成 core dump 文件，我们需要修改一下设置。如果你和我一样懒得修改配置文件，那么就输入下面这样命令吧。

$ sudo  sh -c "ulimit -c unlimited; ./test" # test 是可执行文件名。

等等…… 我们还是先准备个测试目标。

#include <stdio.h>
#include <stdlib.h>

void test()
{
    char* s = "abc";
    *s = 'x';
}

int main(int argc, char** argv)
{
    test();
    return (EXIT_SUCCESS);
}

很显然，我们在 test() 里面写了一个不该写的东东，这无疑会很严重。生成可执行文件后，执行上面的命令。

$ sudo sh -c "ulimit -c unlimited; ./test"

Segmentation fault (core dumped)

$ ls -l

total 96
-rw------- 1 root  root  167936 2010-01-06 13:30 core
-rwxr-xr-x 1 yuhen yuhen   9166 2010-01-06 13:16 test

这个 core 文件就是被系统 dump 出来的，我们分析目标就是它了。

$ sudo gdb test core

GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.

Reading symbols from .../dist/Debug/test...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0... ...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6... ...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2... ...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
#0  0x080483f4 in test () at main.c:16

warning: Source file is more recent than executable.
16        *s = 'x';

最后这几行提示已经告诉我们错误的原因和代码位置，接下来如何调试就是 gdb 的技巧了，可以先输入 "where" 看看调用堆栈。

(gdb) where

#0  0x080483f4 in test () at main.c:16
#1  0x08048401 in main (argc=1, argv=0xbfd53e44) at main.c:22

(gdb) p s

$1 = 0x80484d0 "abc"

(gdb) info files

Symbols from ".../dist/Debug/test".
Local core dump file:

Local exec file:
    `.../dist/Debug/test', file type elf32-i386.
    Entry point: 0x8048330
    0x08048134 - 0x08048147 is .interp
    ... ...
    0x08048330 - 0x080484ac is .text
    0x080484ac - 0x080484c8 is .fini
    0x080484c8 - 0x080484d4 is .rodata

很显然 "abc" 属于 .rodata，严禁调戏。

----------------

附：如果你调试的是 Release (-O2) 版本，而且删除(strip)了符号表，那还是老老实实数汇编代码吧。可见用 Debug 版本试运行是很重要滴！！！

分享到：