当前位置:文档之家› linux段错误

linux段错误

linux段错误
linux段错误

https://www.doczj.com/doc/8f2184200.html,/panfeng412/archive/2011/11/06/2237857.html

Linux环境下段错误的产生原因及调试方法小结

最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是著名的“段错误”(Segmentation Fault)。借此机会系统学习了一下,这里对Linux 环境下的段错误做个小结,方便以后同类问题的排查与解决。

1. 段错误是什么

一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义(参考https://www.doczj.com/doc/8f2184200.html,):

A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer

software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.

Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.

On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.

2. 段错误产生的原因

2.1 访问不存在的内存地址

#include

#include

void main()

{

int *ptr = NULL;

*ptr = 0;

}

2.2 访问系统保护的内存地址

#include

#include

void main()

{

int *ptr = (int *)0;

*ptr = 100;

}

2.3 访问只读的内存地址

#include

#include

#include

void main()

{

char *ptr = "test";

strcpy(ptr, "TEST");

}

2.4 栈溢出

#include

#include

void main()

{

main();

}

等等其他原因。

3. 段错误信息的获取

程序发生段错误时,提示信息很少,下面有几种查看段错误的发生信息的途径。

3.1 dmesg

dmesg可以在应用程序crash掉时,显示内核中保存的相关信息。如下所示,通过dmesg命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。以程序2.3为例:panfeng@ubuntu:~/segfault$ dmesg

[ 2329.479037] segfault3[2700]: segfault at 80484e0 ip 00d2906a sp bfbbec3c error 7 in libc-2.10.1.so[cb4000+13e000]

3.2 -g

使用gcc编译程序的源码时,加上-g参数,这样可以使得生成的二进制文件中加入可以用于gdb调试的有用信息。以程序2.3为例:

panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

3.3 nm

使用nm命令列出二进制文件中的符号表,包括符号地址、符号类型、符号名等,这样可以帮助定位在哪里发生了段错误。以程序2.3为例:

panfeng@ubuntu:~/segfault$ nm segfault3

08049f20 d _DYNAMIC

08049ff4 d _GLOBAL_OFFSET_TABLE_

080484dc R _IO_stdin_used

w _Jv_RegisterClasses

08049f10 d __CTOR_END__

08049f0c d __CTOR_LIST__

08049f18 D __DTOR_END__

08049f14 d __DTOR_LIST__

080484ec r __FRAME_END__

08049f1c d __JCR_END__

08049f1c d __JCR_LIST__

0804a014 A __bss_start

0804a00c D __data_start

08048490 t __do_global_ctors_aux

08048360 t __do_global_dtors_aux

0804a010 D __dso_handle

w __gmon_start__

0804848a T __i686.get_pc_thunk.bx

08049f0c d __init_array_end

08049f0c d __init_array_start

08048420 T __libc_csu_fini

08048430 T __libc_csu_init

U __libc_start_main@@GLIBC_2.0

0804a014 A _edata

0804a01c A _end

080484bc T _fini

080484d8 R _fp_hw

080482bc T _init

08048330 T _start

0804a014 b completed.6990

0804a00c W data_start

0804a018 b dtor_idx.6992

080483c0 t frame_dummy

080483e4 T main

U memcpy@@GLIBC_2.0

3.4 ldd

使用ldd命令查看二进制程序的共享链接库依赖,包括库的名称、起始地址,这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。以程序2.3为例:

panfeng@ubuntu:~/segfault$ ldd ./segfault3

linux-gate.so.1 => (0x00e08000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00675000)

/lib/ld-linux.so.2 (0x00482000)

4. 段错误的调试方法

4.1 使用printf输出信息

这个是看似最简单但往往很多情况下十分有效的调试方式,也许可以说是程序员用的最多的调试方式。简单来说,就是在程序的重要代码附近加上像printf这类输出信息,这样可以跟踪并打印出段错误在代码中可能出现的位置。

为了方便使用这种方法,可以使用条件编译指令#ifdef DEBUG和#endif把printf函数包起来。这样在程序编译时,如果加上-DDEBUG参数就能查看调试信息;否则不加该参数就不会显示调试信息。

4.2 使用gcc和gdb

1、为了能够使用gdb调试程序,在编译阶段加上-g参数,以程序2.3为例:

panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

2、使用gdb命令调试程序:

panfeng@ubuntu:~/segfault$ gdb ./segfault3

GNU gdb (GDB) 7.0-ubuntu

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

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 "i486-linux-gnu".

For bug reporting instructions, please see:

...

Reading symbols from /home/panfeng/segfault/segfault3...done.

(gdb)

3、进入gdb后,运行程序:

(gdb) run

Starting program: /home/panfeng/segfault/segfault3

Program received signal SIGSEGV, Segmentation fault.

0x001a306a in memcpy () from /lib/tls/i686/cmov/libc.so.6

(gdb)

从输出看出,程序2.3收到SIGSEGV信号,触发段错误,并提示地址0x001a306a、调用memcpy报的错,位于

/lib/tls/i686/cmov/libc.so.6库中。

4、完成调试后,输入quit命令退出gdb:

(gdb) quit

A debugging session is active.

Inferior 1 [process 3207] will be killed.

Quit anyway? (y or n) y

1、仅当能确定程序一定会发生段错误的情况下使用。

2、当程序的源码可以获得的情况下,使用-g参数编译程序。

3、一般用于测试阶段,生产环境下gdb会有副作用:使程序运行减慢,运行不够稳定,等等。

4、即使在测试阶段,如果程序过于复杂,gdb也不能处理。

4.3 使用core文件和gdb

在4.2节中提到段错误会触发SIGSEGV信号,通过man 7 signal,可以看到SIGSEGV默认的handler会打印段错误出错信息,并产生core文件,由此我们可以借助于程序异常退出时生成的core文件中的调试信息,使用gdb工具来调试程序中的段错误。

1、在一些Linux版本下,默认是不产生core文件的,首先可以查看一下系统core文件的大小限制:

panfeng@ubuntu:~/segfault$ ulimit -c

2、可以看到默认设置情况下,本机Linux环境下发生段错误时不会自动生成core文件,下面设置下core文件的大小限制(单位为KB):

panfeng@ubuntu:~/segfault$ ulimit -c 1024

panfeng@ubuntu:~/segfault$ ulimit -c

1024

3、运行程序2.3,发生段错误生成core文件:

panfeng@ubuntu:~/segfault$ ./segfault3

段错误(core dumped)

4、加载core文件,使用gdb工具进行调试:

panfeng@ubuntu:~/segfault$ gdb ./segfault3 ./core

GNU gdb (GDB) 7.0-ubuntu

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

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 "i486-linux-gnu".

For bug reporting instructions, please see:

...

Reading symbols from /home/panfeng/segfault/segfault3...done.

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

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

Loaded symbols for /lib/tls/i686/cmov/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 `./segfault3'.

Program terminated with signal 11, Segmentation fault.

#0 0x0018506a in memcpy () from /lib/tls/i686/cmov/libc.6

从输出看出,同4.2.1中一样的段错误信息。

5、完成调试后,输入quit命令退出gdb:

(gdb) quit

1、适合于在实际生成环境下调试程序的段错误(即在不用重新发生段错误的情况下重现段错误)。

2、当程序很复杂,core文件相当大时,该方法不可用。

4.4 使用objdump

1、使用dmesg命令,找到最近发生的段错误输出信息:

panfeng@ubuntu:~/segfault$ dmesg

... ...

[17257.502808] segfault3[3320]: segfault at 80484e0 ip 0018506a sp bfc1cd6c error 7 in libc-2.10.1.so[110000+13e000] 其中,对我们接下来的调试过程有用的是发生段错误的地址:80484e0和指令指针地址:0018506a。

2、使用objdump生成二进制的相关信息,重定向到文件中:

panfeng@ubuntu:~/segfault$ objdump -d ./segfault3 > segfault3Dump

其中,生成的segfault3Dump文件中包含了二进制文件的segfault3的汇编代码。

3、在segfault3Dump文件中查找发生段错误的地址:

panfeng@ubuntu:~/segfault$ grep -n -A 10 -B 10 "80484e0" ./segfault3Dump

121- 80483df: ff d0 call*%eax

122- 80483e1: c9 leave

123- 80483e2: c3 ret

124- 80483e3: 90 nop

126-080483e4

:

127- 80483e4: 55 push %ebp

128- 80483e5: 89 e5 mov %esp,%ebp

129- 80483e7: 83 e4 f0 and $0xfffffff0,%esp

130- 80483ea: 83 ec 20 sub $0x20,%esp

131: 80483ed: c7 44 24 1c e0 84 04 movl $0x80484e0,0x1c(%esp)

132- 80483f4: 08

133- 80483f5: b8 e5 84 04 08 mov $0x80484e5,%eax

134- 80483fa: c7 44 24 08 05 00 00 movl $0x5,0x8(%esp)

135- 8048401: 00

136- 8048402: 89 44 24 04 mov %eax,0x4(%esp)

137- 8048406: 8b 44 24 1c mov 0x1c(%esp),%eax

138- 804840a: 89 04 24 mov %eax,(%esp)

139- 804840d: e8 0a ff ff ff call804831c

140- 8048412: c9 leave

141- 8048413: c3 ret

通过对以上汇编代码分析,得知段错误发生main函数,对应的汇编指令是movl $0x80484e0,0x1c(%esp),接下来打开程序的源码,找到汇编指令对应的源码,也就定位到段错误了。

1、不需要-g参数编译,不需要借助于core文件,但需要有一定的汇编语言基础。

2、如果使用了gcc编译优化参数(-O1,-O2,-O3)的话,生成的汇编指令将会被优化,使得调试过程有些难度。

4.5 使用catchsegv

catchsegv命令专门用来扑获段错误,它通过动态加载器(ld-linux.so)的预加载机制(PRELOAD)把一个事先写好的库(/lib/libSegFault.so)加载上,用于捕捉断错误的出错信息。

panfeng@ubuntu:~/segfault$ catchsegv ./segfault3

Segmentation fault (core dumped)

*** Segmentation fault

Register dump:

EAX: 00000000 EBX: 00fb3ff4 ECX: 00000002 EDX: 00000000

ESI: 080484e5 EDI: 080484e0 EBP: bfb7ad38 ESP: bfb7ad0c

EIP: 00ee806a EFLAGS: 00010203

CS: 0073 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b

Trap: 0000000e Error: 00000007 OldMask: 00000000

ESP/signal: bfb7ad0c CR2: 080484e0

Backtrace:

/lib/libSegFault.so[0x3b606f]

??:0(??)[0xc76400]

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xe89b56]

/build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8048351]

Memory map:

00258000-00273000 r-xp 00000000 08:01 157 /lib/ld-2.10.1.so

00273000-00274000 r--p 0001a000 08:01 157 /lib/ld-2.10.1.so

00274000-00275000 rw-p 0001b000 08:01 157 /lib/ld-2.10.1.so

003b4000-003b7000 r-xp 00000000 08:01 13105 /lib/libSegFault.so

003b7000-003b8000 r--p 00002000 08:01 13105 /lib/libSegFault.so

003b8000-003b9000 rw-p 00003000 08:01 13105 /lib/libSegFault.so

00c76000-00c77000 r-xp 00000000 00:00 0 [vdso]

00e0d000-00e29000 r-xp 00000000 08:01 4817 /lib/libgcc_s.so.1

00e29000-00e2a000 r--p 0001b000 08:01 4817 /lib/libgcc_s.so.1

00e2a000-00e2b000 rw-p 0001c000 08:01 4817 /lib/libgcc_s.so.1

00e73000-00fb1000 r-xp 00000000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so

00fb1000-00fb2000 ---p 0013e000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so

00fb2000-00fb4000 r--p 0013e000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so

00fb4000-00fb5000 rw-p 00140000 08:01 1800 /lib/tls/i686/cmov/libc-2.10.1.so

00fb5000-00fb8000 rw-p 00000000 00:00 0

08048000-08049000 r-xp 00000000 08:01 303895 /home/panfeng/segfault/segfault3

08049000-0804a000 r--p 00000000 08:01 303895 /home/panfeng/segfault/segfault3

0804a000-0804b000 rw-p 00001000 08:01 303895 /home/panfeng/segfault/segfault3

09432000-09457000 rw-p 00000000 00:00 0 [heap]

b78cf000-b78d1000 rw-p 00000000 00:00 0

b78df000-b78e1000 rw-p 00000000 00:00 0

bfb67000-bfb7c000 rw-p 00000000 00:00 0 [stack]

5. 一些注意事项

1、出现段错误时,首先应该想到段错误的定义,从它出发考虑引发错误的原因。

2、在使用指针时,定义了指针后记得初始化指针,在使用的时候记得判断是否为NULL。

3、在使用数组时,注意数组是否被初始化,数组下标是否越界,数组元素是否存在等。

4、在访问变量时,注意变量所占地址空间是否已经被程序释放掉。

5、在处理变量时,注意变量的格式控制是否合理等。

6. 参考资料列表

1、https://www.doczj.com/doc/8f2184200.html,/p-105923877.html

2、https://www.doczj.com/doc/8f2184200.html,/space.php?uid=317451&do=blog&id=92412

linux C用户态调试追踪函数调用堆栈以及定位段错误

linux C用户态调试追踪函数调用堆栈以及定位段错误 一般察看函数运行时堆栈的方法是使用GDB(bt命令)之类的外部调试器,但是,有些时候为了分析程序的BUG,(主要针对长时间运行程序的分析),在程序出错时打印出函数的调用堆栈是非常有用的。 在glibc头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈。 int backtrace(void **buffer,int size) 该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数size 用来指定buffer中可以保存多少个void* 元素。函数返回值是实际获取的指针个数,最大不超过size大小 在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址 注意:某些编译器的优化选项对获取正确的调用堆栈有干扰,另外内联函数没有堆栈框架;删除框架指针也会导致无法正确解析堆栈内容 char ** backtrace_symbols (void *const *buffer, int size) backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的指针数组,size是该数组中的元素个数(backtrace的返回值) 函数返回值是一个指向字符串数组的指针,它的大小同buffer相同.每个字符串包含了一个相对于buffer中对应元素的可打印信息.它包括函数名,函数的偏移地址,和实际的返回地址 现在,只有使用ELF二进制格式的程序才能获取函数名称和偏移地址.在其他系统,只有16进制的返回地址能被获取.另外,你可能需要传递相应的符号给链接器,以能支持函数名功能(比如,在使用GNU ld链接器的系统中,你需要传递(-rdynamic),-rdynamic可用来通知链接器将所有符号添加到动态符号表中,如果你的链接器支持-rdynamic的话,建议将其加上!) 该函数的返回值是通过malloc函数申请的空间,因此调用者必须使用free函数来释放指针. 注意:如果不能为字符串获取足够的空间函数的返回值将会为NULL void backtrace_symbols_fd (void *const *buffer, int size, int fd)

linux错误码大全

linux错误码大全 查看错误代码errno是调试程序的一个重要方法。当linuc C api函数发生异常时,一般会将errno变量(需include errno.h)赋一个整数值,不同的值表示不同的含义,可以通过查看该值推测出错的原因。在实际编程中用这一招解决了不少原本看来莫名其妙的问题。比较麻烦的是每次都要去linux源代码里面查找错误代码的含义,现在把它贴出来,以后需要查时就来这里看了。 1-34号错误号是在内核源码的include/asm-generic/errno-base.h定义 35-132则是在include/asm-generic/errno.h中定义 剩下还有一些更大的错误号是留给内核级别的,如系统调用等,用户程序一般是看不见的这些号的,Ubuntu9.10中 /usr/src/linux-headers-2.6.31-21-generic/include/linux/errno.h #ifndef _ASM_GENERIC_ERRNO_BASE_H #define _ASM_GENERIC_ERRNO_BASE_H #define EPERM 1 /* Operation not permitted */ #define ENOENT 2 /* No such file or directory */ #define ESRCH 3 /* No such process */ #define EINTR 4 /* Interrupted system call */ #define EIO 5 /* I/O error */ #define ENXIO 6 /* No such device or address */ #define E2BIG 7 /* Argument list too long */ #define ENOEXEC 8 /* Exec format error */ #define EBADF 9 /* Bad file number */ #define ECHILD 10 /* No child processes */ #define EAGAIN 11 /* Try again */ #define ENOMEM 12 /* Out of memory */ #define EACCES 13 /* Permission denied */ #define EFAULT 14 /* Bad address */ #define ENOTBLK 15 /* Block device required */ #define EBUSY 16 /* Device or resource busy */ #define EEXIST 17 /* File exists */ #define EXDEV 18 /* Cross-device link */ #define ENODEV 19 /* No such device */

c语言段错误小结

C段错误总结 C语言2009-02-17 11:49:51 阅读21 评论0 字号:大中小订阅 最近一段时间在linux下用C做一些学习和开发,但是由于经验不足,问题多多。而段错误就是让我非常头痛的一个问题。不过,目前写几百行的代码,也很少出现段错误,或者是即使出现了,也很容易找出来,并且处理掉。 那什么是段错误?段错误为什么是个麻烦事?以及怎么发现程序中的段错误以及如何避免发生段错误呢? 一方面为了给自己的学习做个总结,另一方面由于至今没有找到一个比较全面介绍这个虽然是“FREQUENTLY ASKED QUESTIONS”的问题,所以我来做个抛砖引玉吧。下面就从上面的几个问题出发来探讨一下“Segmentation faults"吧。 目录 1。什么是段错误? 2。为什么段错误这么“麻烦”? 3。编程中通常碰到段错误的地方有哪些? 4。如何发现程序中的段错误并处理掉? 正文 1。什么是段错误? 下面是来自https://www.doczj.com/doc/8f2184200.html,的定义: A segmentation fault(often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors. Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.

Linux服务器常用命令(简化版)

Linux服务器常用命令(简化版) 信息来源:网络整理:HY 日期:2011-5-27 Intel Fortran编译 Linux shell管道命令(pipe)使用及与shell重定向 Linux命令替换 Linux 任务控制(bg jobs fg nohup &) Linux进程查看 Linux账户管理 Linux系统与硬盘信息查询 Linux VIM语法高亮与程序段错误 Linux十大常用命令

Intel Fortran编译 完整编译顺序 $ ifort -c Hello.f90 -o Hello.o编译源文件(.f90)生成目标文件(.o) $ ifort Hello.o -o Hello链接目标文件生成可执行程序Hello $./Hello 执行可执行程序 默认(常用编译方法) $ ifort Hello.f90编译&链接 $./a.out 执行a.out(默认可执行程序名) 后台运行 $ ./a.out & 后台运行,退出shell会使程序停止,输出信息会显示在屏幕,不建议这样使用$nohup ./a.out & 输出到屏幕的信息输出到nohup.out文件 $nohup ./a.out > screen.txt & 输出到屏幕的信息输出到screen.txt文件(推荐) Linux shell管道命令(pipe)使用及与shell重定向 Ref:https://www.doczj.com/doc/8f2184200.html,/chengmo/archive/2010/10/21/1856577.html 重定向 详细解释参考:https://www.doczj.com/doc/8f2184200.html,/view/2173319.htm 在Linux命令行模式中,如果命令所需的输入不是来自键盘,而是来自指定的文件,这就是输入重定向。同理,命令的输出也可以不显示在屏幕上,而是写入到指定文件中,这就是输出重定向。 重定向分为: 重定向分为 输出重定向、输入重定向和错误重定向。 < 实现输入重定向。 >或>> 实现输出重定向,用户可以使用输出重定向把一个命令的输出重定向到一个文件 1)ls –l /etc>dir 将ls命令生成的/etc目录下的一个清单存到当前目录 中的dir文件,而不在屏幕输出。 2)ls –l /usr>>dir 将ls命令生成的/usr目录的一个清单以追加的方式存 到当前目录中的dir文件中。 重定向连接两个或多个文件? 使用cat命令并重定向输出到一个文件可以连接两个或多个文件。 重定向追加到一个文件:可以使用双重定向输出符号“>>”,保留文件以前的内容。 这种情况下,命令输出追加到另一个文件中。 重定向重定向标准输出到一个设备? 除了重定向一个命令的输出到一个文件,也可以把它重定向到一个设备,因为UNIX系统将设备当做文件。 $echo “Hello! I am petter!” > /dev/tty01 重定向标准输入? 使用“<”重定向输入。例如:用户已经创建好了一个文件letter。如果希望通过电子邮件发送给用户petter。可以使用下面方式:$mail petter < letter 重定向标准错误重定向? 没有专门的符号用于重定向stderr。我们可以同样使用“< ”或“>”符号,但需在它前面补一个数字2。 PS:重定向的优先级大于管道的优先级!^_^ 管道右边的命令只能对管道左边的命令的标准输出(输出到屏幕)起作用,不对错误输出(也输出到屏幕)起作用。 一个命令的执行首先决定0,1,2设备的定向,然后才执行命令,可以将定向理解为命令执行

Linux段错误(精)

1 执行socket文件时,出现段错误 (core dumped 产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址. 解决方法: 利用gdb逐步查找段错误: 首先我们需要一个带有调试信息的可执行程序,所以我们加上“-g -rdynamic"的参数进行编译,然后用gdb调试运行这个新编译的程序,具体步骤如下: 1、 gcc -g -rdynamic d.c 2、 gdb ./a.out 3、 r 这样就找到了出错位置。然后在相应位置修改。 2 linux 段错误如何调试 linux下的c程序常常会因为内存访问错误等原因造成segment fault(段错误)此时如果系统core dump功能是打开的,那么将会有内存映像转储到硬盘上来,之后可以用gdb对core文件进行分析,还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。

使用ulimit -a可以查看系统core文件的大小限制;使用ulimit -c [kbytes]可以设置系统允许生成的core文件大小。 ulimit -c 0 不产生core文件 ulimit -c 100 设置core文件最大为100k ulimit -c unlimited 不限制core文件大小 步骤: 1、当发生段错误时,我们查看ulimit -a (core file size (blocks, -c 0)并没有文件, 2、设置:ulimit -c unlimited 不限制core文件大小 3.、运行程序,发生段错误时会自动记录在core中 4、test]$ ls -al core.* 在那个文件下(-rw------- 1 leconte leconte 139264 01-06 22:3 1 core.2065) 5、使用gdb 运行程序和段错误记录的文件。(est]$ gdb ./test core.2065) 6、会提哪行有错。 很多系统默认的core文件大小都是0,我们可以通过在Shell的启动脚本/etc/bashrc或者~/.bashrc等地方来加入ulimit -c 命令来指定core文件大小,从而确保core文件能够生成。 除此之外,还可以在/proc/sys/kernel/core_pattern里设置core文件的文件名模板,详情请看core的官方man手册。

浅析Linux下core文件

浅析Linux下core文件 当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方。最常出现的,几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。 何谓core文件 当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的。 当程序接收到以下UNIX信号会产生core文件: 名字说明ANSI C POSIX.1SVR4 4.3+BSD 缺省动作 SIGABRT异常终止(abort) . . . .终止w/core SIGBUS硬件故障 . . .终止w/core SIGEMT硬件故障 . .终止w/core SIGFPE算术异常 . . . .终止w/core SIGILL非法硬件指令 . . . .终止w/core SIGIOT硬件故障 . .终止w/core SIGQUIT终端退出符 . . .终止w/core SIGSEGV无效存储访问 . . . .终止w/core SIGSYS无效系统调用 . .终止w/core SIGTRAP硬件故障 . .终止w/core SIGXCPU超过CPU限制 (setrlimit) . .终止w/core

SIGXFSZ超过文件长度限 . .终止w/core 制(setrlimit) 在系统默认动作列,“终止w/core”表示在进程当前工作目录的core文件中复制了该进程的存储图像(该文件名为core,由此可以看出这种功能很久之前就是UNIX功能的一部分)。大多数UNIX调试程序都使用core 文件以检查进程在终止时的状态。 core文件的产生不是POSIX.1所属部分,而是很多UNIX版本的实现特征。UNIX第6版没有检查条件(a)和(b),并且其源代码中包含如下说明:“如果你正在找寻保护信号,那么当设置-用户-ID命令执行时,将可能产生大量的这种信号”。4.3 + BSD产生名为core.prog的文件,其中prog是被执行的程序名的前1 6个字符。它对core文件给予了某种标识,所以是一种改进特征。 表中“硬件故障”对应于实现定义的硬件故障。这些名字中有很多取自UNIX早先在DP-11上的实现。请查看你所使用的系统的手册,以确切地确定这些信号对应于哪些错误类型。 下面比较详细地说明这些信号。 ? SIGABRT 调用abort函数时产生此信号。进程异常终止。 ? SIGBUS 指示一个实现定义的硬件故障。 ? SIGEMT 指示一个实现定义的硬件故障。 EMT这一名字来自PDP-11的emulator trap 指令。 ? SIGFPE 此信号表示一个算术运算异常,例如除以0,浮点溢出等。 ? SIGILL 此信号指示进程已执行一条非法硬件指令。 4.3BSD由abort函数产生此信号。SIGABRT现在被用于此。

去年Linux复习题(全)

1. Linux文件权限一共10位长度,分成四段,第三段表示的内容是( )。 A 文件类型 B 文件所有者的权限 C 文件所有者所在组的权限 D 其他用户的权限 2. 终止一个前台进程可能用到的命令和操作( )。 A kill B ctrl + C C shut down D halt 3.在使用mkdir命令创建新的目录时,在其父目录不存在时先创建父目录的选项是( )。 A –m B -d C -f D –p 4. 一个文件名字为rr.Z,可以用来解压缩的命令是( )。 A tar B gzip C compress D uncompress 5. 下列提法中,不属于ifconfig命令作用范围的是( )。 A 配置本地回环地址 B 配置网卡的IP地址 C 激活网络适配器 D 加载网卡到内核中 6. 下列不是Linux系统进程类型的是( )。 A 交互进程 B 批处理进程 C 守护进程 D 就绪进程 7. 内核不包括的子系统是 ( )。 A 进程管理系统 B 内存管理系统 C I/O管理系统D硬件管理系统 8.若一台计算机的内存为128MB,则交换分区的大小通常是( )。 A 64M B B 128MB C 256MB D 512MB 10.在TCP/IP模型中,应用层包含了所有的高层协议,在下列的一些应用协议中,是能够实现本地与远程主机之间的文件传输工作( )。 A telnet B FTP C SNMP D NFS 11.对名为fido的文件用chmod 551 fido 进行了修改,则它的许可权是 ( )。 A -rwxr-xr-x B -rwxr--r— C -r--r--r— D -r-xr-x—x 12.用ls –al 命令列出下面的文件列表, ( )文件是符号连接文件。 A -rw-rw-rw- 2 hel-s users 56 Sep 09 11:05 hello B -rwxrwxrwx 2 hel-s users 56 Sep 09 11:05 goodbey C drwxr--r-- 1 hel users 1024 Sep 10 08:10 zhang D lrwxr--r-- 1 hel users 2024 Sep 12 08:12 cheng 13.NFS是系统( )。 A 文件 B 磁盘 C 网络文件 D 操作 14.Linux文件系统的文件都按其作用分门别类地放在相关的目录中,对于外部设备文件,一般应将其放在( ) 目录中。 A /bin B /etc C /dev D /lib 15.关闭linux系统(不重新启动)可使用命令( )。 A Ctrl+Alt+Del B halt C shutdown -r now D reboot 16.用命令ls -al显示出文件ff的描述如下所示,由此可知文件ff的类型为( ) 。 -rwxr-xr-- 1 root root 599 Cec 10 17:12 ff A 普通文件 B 硬链接 C 目录 D 符号链接 17.删除文件命令为:( ) 。 A mkdir B rmdir C mv D rm 18.对文件进行归档的命令为( ) 。 A dd B cpio C gzip D tar

Linux下segment fault的调试

Linux下的段错误产生的原因及调试方法 简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在 对应的物理内存,尤其常见的是访问0地址. 一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是 由gdtr来保存的,他是一个48位的寄存器,其中的32位是保存由它指向的gdt表,后 13位保存相应于gdt的下标,最后3位包括了程序是否在内存中以及程序的在cpu中的运 行级别,指向的gdt是由以64位为一个单位的表,在这张表中就保存着程序运行的代码段 以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等 等的信息。一旦一个程序发生了越界访问,cpu就会产生相应的异常保护,于是 segmentation fault就出现了. 在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的 1)访问系统数据区,尤其是往系统保护的内存地址写数据 最常见就是给一个指针以0地址

2)内存越界(数组越界,变量类型不一致等)访问到不属于你的内存区域解决方法 我们在用C/C++语言写程序的时侯,内存管理的绝大部分工作都是需要我们来做的。实际 上,内存管理是一个比较繁琐的工作,无论你多高明,经验多丰富,难免会在此处犯些 小错误,而通常这些错误又是那么的浅显而易于消除。但是手工“除虫”(debug),往 往是效率低下且让人厌烦的,本文将就"段错误"这个内存访问越界的错误谈谈如何快速定 位这些"段错误"的语句。 下面将就以下的一个存在段错误的程序介绍几种调试方法: 1dummy_function(void) 2{ 3unsigned char*ptr=0x00; 4*ptr=0x00; 5} 6 7int main(void) 8{ 9dummy_function(); 10

嵌入式linux课程-野指针与段错误

野指针与段错误 1、野指针与段错误问题 1.1、什么是野指针? 所谓野指针就是,指针指向一个不确定的地址空间,或者指向的是一个确定的地址空间的,但引用空间的结果却是不可预知的,这样的指针就称为野指针。 例子1: int main(void){ int*p; *p=10; return0; } 本例子中,p是自动局部变量,由于p没有被初始化,也没有被后续赋值,那么p中存放的是一个随机值,所以p指向的内存空间是不确定的,访问一个不确定的地址空间,结果显然是不可预知的。 例子1: int main(void){ int*p=0x13542354; *p=10; return0; } 本例子中,p虽然是指向了一个确定地址“0x43542354”的空间,但是它对应的空间是否存在,其读写权限是否满足程序的访问要求,都是未知数,所以导致的结果也是未知的。 通过以上两个例子了解到,在给指针变量绑定地址,指向某个空间时,一定要是确定的,不能出现不可预知性,一旦出现未知性它就是一个野指针,即使某一次没有产生严重后果,但埋下了这颗地雷后,就留下了不可预知的隐患,对于程序来说这是不可接受的。 1.2、野指针可能引发的危害 (1)引发段错误 段错误就是地址错误,其实是一种对程序和系统的保护性措施,一旦产生段错误,程序会立即终止,防止错误循环叠加,产生雪崩式的错误。 (2)未产生任何结果 有的时候,可能使用了一个野指针,虽然指向了一个未知的地址空间,但是这空间可以使用,而且该空间和程序中的其它变量空间没有交集,对野指针指向的空间进行了读写访问后,也不会对程序产生任何影响,虽然如此,这种野指针也是必须要极力避免的,因为这个隐患很可能在后面的程序运行中,导致严重的错误,而且这种错误很难排查。 (3)引发程序连环式错误 访问野指针产生的错误循环叠加,轻者程序结果严重扭曲,重者直接导致程序或者系统崩溃。 1.3、野指针产生的原因

linux基础实验报告含代码

Linux基础实验

目录 实验一 (3) 实验二 (4) 实验三 (6) 实验四 (9) 实验五 (11) 实验六 (14) 实验七 (16)

实验一螺旋矩阵 一、实验目的 1.熟悉linux下c程序编写。 2.掌握Makefile编写方法。 二、实验环境和工具 Red Hat Linux 三、实验流程 1.编写螺旋矩阵程序 2.编写Makefile文件 四、实验结果 五、实验心得 通过这次实验,我熟悉了linux下c语言程序的编写,掌握了vi的一些常用操作,学会了使用gcc命令和makefile文件两种方法编译程序。同时也使我熟悉了linux里常用命令的使 用,还有,学会了挂载U盘的方法,可以很方便的往linux里传送文件。 六、关键代码 Makefile 文件 CC=gcc EXEC=juzhen OBJS=juzhen.o all:$(EXEC) $(EXEC):$(OBJS) $(CC) -o $@ $(OBJS) clean: -rm -f $(EXEC) $(OBJS)

实验二添加、删除用户 一、实验目的 1.设计一个shell程序,分组批量添加用户。 2.再设计一个批量删除用户的shell程序。 二、实验环境和工具 Red Hat Linux 三、实验流程 1.编写shell程序 2.修改文件权限 chmod +x addusers 3.运行脚本 四、实验结果 添加用户: 删除用户:

五、实验心得 通过本次实验,我了解了shell脚本编程的方法和其语法规则。掌握了使用shell脚本程序添加、删除用户的方法。需要注意的是:shell脚本直接用vi编写,要特别注意空格。 六、关键代码 添加用户: 删除用户:

段错误(core dumped)

段错误 (core dumped) 当我们的程序崩溃时,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方。最常出现的,几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。 何谓core文件 当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的。 使用core文件调试程序 看下面的例子: #include char *str = "test"; void core_test(){ str[1] ='T'; } int main(){ core_test(); return0; } 编译: gcc –g core_dump_test.c -o core_dump_test 如果需要调试程序的话,使用gcc编译时加上-g选项,这样调试core文件的时候比较容易找到错误的地方。 执行: ./core_dump_test 段错误 运行core_dump_test程序出现了“段错误”,但没有产生core文件。这是因为系统默认core文件的大小为0,所以没有创建。可以用ulimit命令查看和修改core文件的大小。ulimit -c 0 ulimit -c 1000

ulimit -c 1000 -c指定修改core文件的大小,1000指定了core文件大小。也可以对core文件的大小不做限制,如: ulimit -c unlimited ulimit -c unlimited 如果想让修改永久生效,则需要修改配置文件,如.bash_profile、/etc/profile或 /etc/security/limits.conf。 再次执行: ./core_dump_test 段错误 (core dumped) ls core.* core.6133 可以看到已经创建了一个core.6133的文件.6133是core_dump_test程序运行的进程ID。调式core文件 core文件是个二进制文件,需要用相应的工具来分析程序崩溃时的内存映像。 file core.6133 core.6133: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV),SVR4-style, from 'core_dump_test' 在Linux下可以用GDB来调试core文件。 gdb core_dump_test core.6133 GNU gdb Red Hat Linux(5.3post-0.20021129.18rh) Copyright 2003 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 certainconditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type"show warranty" for details. This GDB was configured as"i386-redhat-linux-gnu"... Core was generated by `./core_dump_test'. Program terminated with signal 11, Segmentationfault.

Linux下的段错误产生的原因及调试方法(精)

简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址. 一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间,通常这个值是由gdtr来保存的,他是一个48位的寄存器,其中的32位是保存由它指向的gdt表,后13位保存相应于gdt的下标,最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表,在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访问,cpu就会产生相应的异常保护,于是segmentation fault就出现了. 在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的 1)访问系统数据区,尤其是往系统保护的内存地址写数据 最常见就是给一个指针以0地址 2)内存越界(数组越界,变量类型不一致等) 访问到不属于你的内存区域 解决方法 我们在用C/C++语言写程序的时侯,内存管理的绝大部分工作都是需要我们来做的。实际上,内存管理是一个比较繁琐的工作,无论你多高明,经验多丰富,难免会在此处犯些小错误,而通常这些错误又是那么的浅显而易于消除。但是手工“除虫”(debug),往往是效率低下且让人厌烦的,本文将就"段错误"这个内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。 下面将就以下的一个存在段错误的程序介绍几种调试方法: 1 dummy_function (void) 2 { 3 unsigned char *ptr = 0x00; 4 *ptr = 0x00; 5 } 6 7 int main (void) 8 { 9 dummy_function (); 10 11 return 0; 12 } 作为一个熟练的C/C++程序员,以上代码的bug应该是很清楚的,因为它尝试操作地址为0的内存区域,而这个内存区域通常是不可访问的禁区,当然就会出错了。我们尝试编译运行它:

Linux段错误解释

Linux下发生段错误时如何产生core文件 摘自: https://www.doczj.com/doc/8f2184200.html,被阅读次数: 129 由yangyi于2010-01-20 21:39:12 提供 Linux下的C程序常常会因为内存访问错误等原因造成segment fault(段错误),此时如果系统core dump功能是打开的,那么将会有内存映像转储到硬盘上来,之后可以用gdb对core 文件进行分析,还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。 使用ulimit -a可以查看系统core文件的大小限制;使用ulimit -c [kbytes]可以设置系统允许生成的core文件大小,例如 ulimit -c 0 不产生core文件 ulimit -c 100 设置core文件最大为100k ulimit -c unlimited 不限制core文件大小 先看一段会造成段错误的程序: #include int main() { char *ptr="linux https://www.doczj.com/doc/8f2184200.html,"; *ptr=0; }

编译运行后结果如下: [leconte@localhost test]$ gcc -g -o test a.c [leconte@localhost test]$ ./test 段错误 此时并没有产生core文件,接下来使用ulimit -c设置core文件大小为无限制,再执行./test程序,结果如下: [leconte@localhost ~]$ ulimit -a core file size (blocks, -c) 0 ......... [leconte@localhost test]$ ulimit -c unlimited [leconte@localhost test]$ ulimit -a core file size (blocks, -c) unlimited .............. [leconte@localhost test]$ ./test 段错误(core dumped)

Linux ELF 运行时内存详解 - 黑客防线官方站

Linux ELF 运行时内存详解 4/22/2012 前一段时间做ROP (return-oriented programming )的东西,想要系统的了解Linux 中程序的内存格式(memory layout ),网上有很多文章,却没有一个深入完整的介绍。所以花了些时间做深入的了解,不放过一个细节。由于最初写的是英文文档,所以文中的图都是用英文标识的,不过应该不影响阅读。 本文详细解释了Linux ELF 文件的虚拟地址空间。另外本文也大概介绍了ASLR (Address Space Layout Randomization)技术对ELF 虚拟地址空间的影响。作者的测试系统是Linux Ubuntu 2.6.32-24和Vmware Workstation 7。另外所有的分析都基于Intel x86架构。 虚拟地址空间 当代的操作系统中每个进程都有自己的独立虚拟地址空间。在32位系统上,该虚拟地址空间有4G 大小。为了将虚拟地址转换为物理地址,Linux 内核使用了一个两级(事实上是三级,但是中间一级没有任何实质操作)分页机制,即页目录表和页表。分页机制与MMU (Memory Management Unit )合作将虚拟地址转换为物理地址。当操作系统引入虚拟地址后,所有的用户操作系统和内核线程(事实上Linux 只有进程概念而没有线程概念,Linux 通过页表机制来模拟实现内核线程)都将运行于虚拟地址模式。 另外Linux (以及Windows )使用了CPU 提供的权限机制。内核代码将运行于ring 0而用户程序运行于ring 3。 因此为了适应该分级机制以及适应多任务机制,Linux 的虚拟地址空间被分为两部分,如图1所示: 0xffff ffff 0x0Linux Virtual Address Split 0xffff ffff 0x0 Windows Virtual Address Split 图1. Linux/Windows 虚拟地址空间的内核部分和用户部分。 Linux 中,内核空间为0xc0000000到0xffffffff 的地址,因此内核代码将被映射到区域。而在Windows 中,默认的分割方式为内核与用户各占2GB 。本文仅详细分析Linux 的地址空间而不再涉及Windows 。下面分两部分介绍Linux 地址空间,首先是内核地址空间然后再介绍用户地址空间。 1. 内核地址空间 黑 客防线 a c k e r .c o m .c n 明出处

Linux软中断的实现

Linux软中断的实现 1.1 注册还是以我最熟悉的两个老朋友做为开篇:open_softirq(NET_TX_SOFTIRQ, net_tx_action); open_softirq(NET_RX_SOFTIRQ, net_rx_action);open_softirq 向内核注册一个软中断,其实质是设置软中断向量表相应槽位,注册其处理函数:void open_softirq(int nr, void (*action)(struct softirq_action *)){ softirq_vec[nr].action = action;}复制代码 softirq_vec是整个软中断的向量表:struct softirq_action{ void (*action)(struct softirq_action *);};static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;复制代码NR_SOFTIRQS是最大软中断向量数,内核支持的所有软中断如下:enum{ HI_SOFTIRQ=0, TIMER_SOFTIRQ, NET_TX_SOFTIRQ, NET_RX_SOFTIRQ, BLOCK_SOFTIRQ, TASKLET_SOFTIRQ, SCHED_SOFTIRQ, HRTIMER_SOFTIRQ, RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */ NR_SOFTIRQS};复制代码好像后为为RPS新增了一个,不过这我的内核版本偏低。1.2 激活当需要调用软中断时,需

c语言段错误及调试总结

标准C语言段错误总结 C语言2009-02-17 11:49:51 阅读21 评论0 字号:大中小订阅 最近一段时间在linux下用C做一些学习和开发,但是由于经验不足,问题多多。而段错误就是让我非常头痛的一个问题。不过,目前写几百行的代码,也很少出现段错误,或者是即使出现了,也很容易找出来,并且处理掉。 那什么是段错误?段错误为什么是个麻烦事?以及怎么发现程序中的段错误以及如何避免发生段错误呢? 一方面为了给自己的学习做个总结,另一方面由于至今没有找到一个比较全面介绍这个虽然是“FREQUENTLY ASKED QUESTIONS”的问题,所以我来做个抛砖引玉吧。下面就从上面的几个问题出发来探讨一下“Segmentation faults"吧。 目录 1。什么是段错误? 2。为什么段错误这么“麻烦”? 3。编程中通常碰到段错误的地方有哪些? 4。如何发现程序中的段错误并处理掉? 正文 1。什么是段错误? 下面是来自https://www.doczj.com/doc/8f2184200.html,的定义: A segmentation fault(often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors. Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.

Linux 段错误

1执行socket文件时,出现段错误(core dumped) 产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址. 解决方法: 利用gdb逐步查找段错误: 首先我们需要一个带有调试信息的可执行程序,所以我们加上―-g -rdynamic"的参数进行编译,然后用gdb调试运行这个新编译的程序,具体步骤如下: 1、gcc -g -rdynamic d.c 2、gdb ./a.out 3、r 这样就找到了出错位臵。然后在相应位臵修改。 2linux 段错误如何调试 linux下的c程序常常会因为内存访问错误等原因造成segment fault(段错误)此时如果系统core dump功能是打开的,那么将会有内存映像转储到硬盘上来,之后可以用gdb对core文件进行分析,还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。 使用ulimit -a可以查看系统core文件的大小限制;使用ulimit -c [kbytes]可以设臵系统允许生成的core文件大小。 ulimit -c 0 不产生core文件 ulimit -c 100 设臵core文件最大为100k ulimit -c unlimited 不限制core文件大小 步骤: 1、当发生段错误时,我们查看ulimit -a (core file size (blocks, -c) 0)并没有文件, 2、设臵:ulimit -c unlimited 不限制core文件大小 3.、运行程序,发生段错误时会自动记录在core中 4、test]$ ls -al core.* 在那个文件下(-rw------- 1 leconte leconte 139264 01-06 22:3 1 core.2065) 5、使用gdb 运行程序和段错误记录的文件。(est]$ gdb ./test core.2065)

相关主题
文本预览
相关文档 最新文档