linux程序段错误原理,Linux 下c 程序段错误分析

落日映苍穹つ 2023-01-20 08:23 10阅读 0赞

fopen("/var/spool/cron/tmp","w+");

＃i nclude ＃i nclude ＃i nclude ＃i nclude ＃i nclude ＃i nclude ＃i nclude

int main()\{

int ret=-1;

printf("\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* delPolicy \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\\n");

FILE \*f;

f=fopen("var/spool/cron/tmp","w");

if(f==NULL)

printf("open tmp failed!\\n");

fclose(f);

return -1;

printf("open two files successfully!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");

fclose(f);

ret=0;

return ret;

出现段错误:

原因:1:"/var/spool/cron/tmp"错写成"var/spool/cron/tmp"

2:文件名不能为tmp关键字,可为mytmp

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

一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gdtr来保存的，它是一个48位的寄存器，

其中的32位是保存由它指向的gdt表，后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,

指向的gdt是由以64位为一个单位的表，在这张表中就保存着程序运行的代码段以及数据段的起始地址,以及与此相应的段限和页面交换,

还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访问，cpu就会产生相应的异常保护，于是segmentation fault就出现了.

在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的

1)访问系统数据区，尤其是往 系统保护的内存地址写数据最常见就是给一个指针以0地址

2)内存越界(数组越界，变量类型不一致等) 访问到不属于你的内存区域

解决方法

我们在用C/C++语言写程序的时侯，内存管理的绝大部分工作都是需要我们来做的。

如何快速定位这些"段错误"的语句

1 dummy\_ (void)

2 \{

3 unsigned char \*ptr = 0x00;

4 \*ptr = 0x00;

5 \}

7 int main (void)

8 \{

9 dummy\_ ();

11 return 0;

12 \}

尝试操作地址为0的内存区域，而这个内存区域通常是不可访问的禁区，出错了。编译运行:

$ ./a.out

段错误

1.利用gdb逐步查找段错误:

需要一个带有调试信息的可执行程序，加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:

$ gcc -g -rdynamic d.c

$ gdb ./a.out

GNU gdb 6.5

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".

(gdb) r

Starting program: /a.out

Program received signal SIGSEGV, Segmentation fault.

0x08048524 in dummy\_ () at d.c:4

4 \*ptr = 0x00;

(gdb) 不用一步步调试就找到了出错位置d.c文件的第4行。

发现进程是由于收到了SIGSEGV信号而结束的。通过进一步的查阅文档(man 7 signal)，

SIGSEGV默认handler的动作是打印”段错误"的出错信息，并产生Core文件，由此又产生了方法二。

2.分析Core文件：

Core文件是什么呢？

The default action of certain signals is to cause a process to terminate and produce a core dump file,

a disk file containing an image of the process's memory at the time of termination. A list of the signals which cause a process to dump core can be found in signal(7).

以 上资料摘自man page(man 5 core)。有时为了渐少系统上的拉圾文件的数量，禁止了core文件的生成，

将系统的core文件的大小限制在512K大小

$ ulimit -c 0

$ ulimit -c 1000

$ ./a.out

段错误 (core dumped)

$ ls

a.out core d.c f.c g.c pango.c test\_iconv.c test\_regex.c

core文件终于产生了，gdb调试:

$ gdb ./a.out core

GNU gdb 6.5

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".

warning: Can't read pathname for load map: 输入/输出错误.

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

Core was generated by \`./a.out'.

Program terminated with signal 11, Segmentation fault.

\#0 0x08048524 in dummy\_ () at d.c:4

4 \*ptr = 0x00;

windows系统下的ie的，有时打开某些网页，会出现“运行时错误”，这个时侯如果恰好你的机器上又装有windows的编译器的话，

它会弹出来一个对话框，问你是否进行调试，如果你选择是，编译器将被打开，并进入调试状态，开始调试。

Linux下如何做到这些？让它在SIGSEGV的handler中调用gdb，于是第三个方法又诞生了:

3.段错误时启动调试:

＃i nclude ＃i nclude ＃i nclude ＃i nclude

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\] = '\\0';

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

system(cmd);

exit(0);

void

dummy\_ (void)

unsigned char \*ptr = 0x00;

\*ptr = 0x00;

int

main (void)

signal(SIGSEGV, &dump);

dummy\_ ();

return 0;

编译运行效果如下:

$ gcc -g -rdynamic f.c

$ ./a.out

GNU gdb 6.5

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\_ () 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进行分析:

重写的代码如下:

＃i nclude ＃i nclude ＃i nclude ＃i nclude

void

dummy\_ (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 s.\\n", size);

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

printf ("%s\\n", strings\[i\]);

free (strings);

exit(0);

int

main (void)

signal(SIGSEGV, &dump);

dummy\_ ();

return 0;

编译运行结果如下：

$ gcc -g -rdynamic g.c

$ ./a.out

Obtained 5 stack s.

./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对应的代码位置:

$ 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 leav

\-----后面内容摘自互联通网

linux程序段错误原理,Linux 下c 程序段错误分析

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 Linux下的段错误产生的原因及调试方法

相关 linux程序段错误原理,Linux 下c 程序段错误分析

相关段错误

相关 C/C++编程：gdb找出程序段错误位置

相关一段python程序_第一段python程序

相关 linux 段错误吐核崩溃简介

相关段错误总结

相关段错误原因分析和查找

相关一段神奇的c代码错误分析

相关汇编语言———数据段、程序段、栈段