至顶网›软件频道 ›基础软件›Linux系统内存错误产生的原因及调试方法(1)

Linux系统内存错误产生的原因及调试方法(1)

扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条

一般而言，在产生内存段错误提示问题时，产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问0地址。

作者：kid 来源：赛迪网 2007年8月27日

关键字：

接着考虑下去，以前用windows系统下的ie的时侯，有时打开某些网页，会出现“运行时错误”，这个时侯如果恰好你的机器上又装有windows的编译器的话，他会弹出来一个对话框，问你是否进行调试，如果你选择是，编译器将被打开，并进入调试状态，开始调试。

Linux下如何做到这些呢？我的大脑飞速地旋转着，有了，让它在SIGSEGV的handler中调用gdb，于是第三个方法又诞生了：

3.段错误时启动调试:

#include

#include

#include

#include

void dump(int signo)

{

char buf[1024];

char cmd[1024];

FILE *fh;

snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());

if(!(fh = fopen(buf, "r")))

exit(0);

if(!fgets(buf, sizeof(buf), fh))

exit(0);

fclose(fh);

if(buf[strlen(buf) - 1] == 'n')

buf[strlen(buf) - 1] = '';

snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());

system(cmd);

exit(0);

}

void

dummy_function (void)

{

unsigned char *ptr = 0x00;

*ptr = 0x00;

}

int

main (void)

{

signal(SIGSEGV, &dump);

dummy_function ();

return 0;

}

编译运行效果如下：

xiaosuo@gentux test $ gcc -g -rdynamic f.c

xiaosuo@gentux test $ ./a.out

GNU gdb 6.5

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /home/xiaosuo/test/a.out, process 9563

Reading symbols from /lib/libc.so.6...done.

Loaded symbols for /lib/libc.so.6

Reading symbols from /lib/ld-linux.so.2...done.

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

0xffffe410 in __kernel_vsyscall ()

(gdb) bt

#0 0xffffe410 in __kernel_vsyscall ()

#1 0xb7ee4b53 in waitpid () from /lib/libc.so.6

#2 0xb7e925c9 in strtold_l () from /lib/libc.so.6

#3 0x08048830 in dump (signo=11) at f.c:22

#4

#5 0x0804884c in dummy_function () at f.c:31

#6 0x08048886 in main () at f.c:38

怎么样？是不是依旧很酷？

以上方法都是在系统上有gdb的前提下进行的，如果没有呢？其实glibc为我们提供了此类能够dump栈内容的函数簇，详见/usr/include/execinfo.h（这些函数都没有提供man page，难怪我们找不到），另外你也可以通过gnu的手册进行学习。

4.利用backtrace和objdump进行分析：

重写的代码如下:

#include

#include

#include

#include

/* A dummy function to make the backtrace more interesting. */

void

dummy_function (void)

{

unsigned char *ptr = 0x00;

*ptr = 0x00;

}

void dump(int signo)

{

void *array[10];

size_t size;

char **strings;

size_t i;

size = backtrace (array, 10);

strings = backtrace_symbols (array, size);

printf ("Obtained %zd stack frames.n", size);

for (i = 0; i < size; i++)

printf ("%sn", strings[i]);

free (strings);

exit(0);

}

int

main (void)

{

signal(SIGSEGV, &dump);

dummy_function ();

return 0;

}

编译运行结果如下：

xiaosuo@gentux test $ gcc -g -rdynamic g.c

xiaosuo@gentux test $ ./a.out

Obtained 5 stack frames.

./a.out(dump+0x19) [0x80486c2]

[0xffffe420]

./a.out(main+0x35) [0x804876f]

/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]

./a.out [0x8048601]

这次你可能有些失望,似乎没能给出足够的信息来标示错误,不急,先看看能分析出来什么吧,用objdump反汇编程序,找到地址0x804876f对应的代码位置:

xiaosuo@gentux test $ objdump -d a.out

8048765: e8 02 fe ff ff call 804856c

804876a: e8 25 ff ff ff call 8048694

804876f: b8 00 00 00 00 mov $0x0,%eax

8048774: c9 leave

我们还是找到了在哪个函数(dummy_function)中出错的,信息已然不是很完整,不过有总比没有好的啊!

后记：

本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。

查看本文来源