可能原因: 1.数组开太大 2.空指针 (遇到新的原因再更新)
可能原因:
1.数组开太大
2.空指针
(遇到新的原因再更新)
谢谢大神,把吐核原因分析的很清楚,先转载部分,原文在这里 详解coredump。https://blog.csdn.net/tenfyguo/article/details/8159176 五,coredump产生的几种可能情况 造成程序coredump的原因有很多,...

五,coredump产生的几种可能情况

造成程序coredump的原因有很多,这里总结一些比较常用的经验吧:
1,内存访问越界
a) 由于使用错误的下标,导致数组访问越界。
b) 搜索字符串时,依靠字符串结束符来判断字符串是否结束,但是字符串没有正常的使用结束符。
c) 使用strcpy, strcat, sprintf, strcmp,strcasecmp等字符串操作函数,将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。
2,多线程程序使用了线程不安全的函数。
应该使用下面这些可重入的函数,它们很容易被用错:
asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n)ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c)getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c)fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c)getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3)getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n)nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3)getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c)getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c)getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)
3,多线程读写的数据未加锁保护。
对于会被多个线程同时访问的全局数据,应该注意加锁保护,否则很容易造成coredump
4,非法指针
a) 使用空指针
b) 随意使用指针转换。一个指向一段内存的指针,除非确定这段内存原先就分配为某种结构或类型,或者这种结构或类型的数组,否则不要将它转换为这种结构或类型的指针,而应该将这段内存拷贝到一个这种结构或类型中,再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的,那么访问它时就很容易因为bus error而core dump。
5,堆栈溢出
不要使用大的局部变量(因为局部变量都分配在栈上),这样容易造成堆栈溢出,破坏系统的栈和堆结构,导致出现莫名其妙的错误。

六,利用gdb进行coredump的定位

其实分析coredump的工具有很多,现在大部分类unix系统都提供了分析coredump文件的工具,不过,我们经常用到的工具是gdb。
这里我们以程序为例子来说明如何进行定位。
1, 段错误 – segmentfault
Ø 我们写一段代码往受到系统保护的地址写内容。
Ø 按如下方式进行编译和执行,注意这里需要-g选项编译。
从红色方框截图可以看到,程序中止是因为信号11,且从bt(backtrace)命令(或者where)可以看到函数的调用栈,即程序执行到coremain.cpp的第5行,且里面调用scanf 函数,而该函数其实内部会调用_IO_vfscanf_internal()函数。
接下来我们继续用gdb,进行调试对应的程序。
记住几个常用的gdb命令:
l(list) ,显示源代码,并且可以看到对应的行号;
b(break)x, x是行号,表示在对应的行号位置设置断点;
p(print)x, x是变量名,表示打印变量x的值
r(run), 表示继续执行到断点的位置
n(next),表示执行下一步
c(continue),表示继续执行
q(quit),表示退出gdb
启动gdb,注意该程序编译需要-g选项进行。
注: SIGSEGV11 Core Invalid memoryreference

七,附注:

1, gdb的查看源码
显示源代码
GDB 可以打印出所调试程序的源代码,当然,在程序编译时一定要加上-g的参数,把源程序信息编译到执行文件中。不然就看不到源程序了。当程序停下来以后,GDB会报告程序停在了那个文件的第几行上。你可以用list命令来打印程序的源代码。还是来看一看查看源代码的GDB命令吧。
list
显示程序第linenum行的周围的源程序。
list
显示函数名为function的函数的源程序。
list
显示当前行后面的源程序。
list -
显示当前行前面的源程序。
一般是打印当前行的上5行和下5行,如果显示函数是是上2行下8行,默认是10行,当然,你也可以定制显示的范围,使用下面命令可以设置一次显示源程序的行数。
setlistsize
设置一次显示源代码的行数。
showlistsize
查看当前listsize的设置。
list命令还有下面的用法:
list,
显示从first行到last行之间的源代码。
list ,
显示从当前行到last行之间的源代码。
list +
往后显示源代码。
一般来说在list后面可以跟以下这些参数:
行号。
当前行号的正偏移量。
当前行号的负偏移量。
哪个文件的哪一行。
函数名。
哪个文件中的哪个函数。
程序运行时的语句在内存中的地址。
2, 一些常用signal的含义
SIGABRT:调用abort函数时产生此信号。进程异常终止。
SIGBUS:指示一个实现定义的硬件故障。
SIGEMT:指示一个实现定义的硬件故障。EMT这一名字来自PDP-11的emulator trap 指令。
SIGFPE:此信号表示一个算术运算异常,例如除以0,浮点溢出等。
SIGILL:此信号指示进程已执行一条非法硬件指令。4.3BSD由abort函数产生此信号。SIGABRT现在被用于此。
SIGIOT:这指示一个实现定义的硬件故障。IOT这个名字来自于PDP-11对于输入/输出TRAP(input/outputTRAP)指令的缩写。系统V的早期版本,由abort函数产生此信号。SIGABRT现在被用于此。
SIGQUIT:当用户在终端上按退出键(一般采用Ctrl-/)时,产生此信号,并送至前台进
程组中的所有进程。此信号不仅终止前台进程组(如SIGINT所做的那样),同时产生一个core文件。
SIGSEGV:指示进程进行了一次无效的存储访问。名字SEGV表示“段违例(segmentationviolation)”。
SIGSYS:指示一个无效的系统调用。由于某种未知原因,进程执行了一条系统调用指令,但其指示系统调用类型的参数却是无效的。
SIGTRAP:指示一个实现定义的硬件故障。此信号名来自于PDP-11的TRAP指令。
SIGXCPUSVR4和4.3+BSD支持资源限制的概念。如果进程超过了其软C P U时间限制,则产生此信号。
SIGXFSZ:如果进程超过了其软文件长度限制,则SVR4和4.3+BSD产生此信号。
3, Core_pattern的格式
可以在core_pattern模板中使用变量还很多,见下面的列表:
%% 单个%字符
%p 所dump进程的进程ID
%u 所dump进程的实际用户ID
%g 所dump进程的实际组ID
%s 导致本次core dump的信号
%t core dump的时间 (由1970年1月1日计起的秒数)
%h 主机名
%e 程序文件名
ulimit -c unlimited 然后通过gdb的bt指令查看函数调用栈
ulimit -c unlimited
然后通过gdb的bt指令查看函数调用栈
吐核:突出了一个“核心转储文件”(core dump文件)也是使用gdb调试器最常用到的场景 查看核心转储文件 ll -a查看全部文件 +默认隐藏文件 其实操作系统有限制,默认不允许随意吐核,影响机器性能 ulimit -a查看...
段错误
我们在Linux环境下编程中,有时执行编译好的文件时会出现段错误(吐核),这是经常出现的一个错误。
它是什么意思呢? 这个错误过程中都有哪些文件? 与VS中IDE直接报错有何不同?我们将通过本篇进行探讨。
查阅相关文档发现,产生段错误的原因主要有:解引用空指针访问不可访问的内存空间(如内核空间)访问不存在的内存地址试图写一个只读内存空间(如代码段)栈溢出(函数递归调用)使用未初始化的指针(定义时没有初始化或者已经回收)
比如我们在程序中对一个空指针进行解引用进行演示:
这里就出现了如开头第一张图中所示的段错误(吐核)
吐核:吐出了一个“核心转储文件”(coredump文件)
程序确认出现错误时的“临终遗言” 写入核心转储文件,也是使用gdb调试器最常用到的场景
那么如何查看吐出的 核心转储文件?
我们尝试ls -a查看全部文件 (包含默认隐藏的文件)发现也并没有相关的新文件产生。
其实操作系统有限制,默认不允许随意吐核,在一个工程中coredump文件有可能会特别大,多次吐核过于占存,这样随意吐核会影响机器性能,一定要慎用。
文件什么样?
我们通过指令查看与程序相关的属性,其中会包含核心转储文件信息:
ulimit -a
第一条core file就是coredump—— 核心转储文件,size为0表示不允许吐核,更改一下文件大小就可以顺利产出吐核文件了。
通过指令更改为大小为无限制
ulimit -c unlimited
我们再执行./main,再次吐核。
之后ls就会出现core.3616文件,数字后缀不同机器会不一样,这个不用在意。这个就是核心转储文件,我们成功通过操作查看到了。
仔细查看文件详情,发现文件确实占存很大:
那么我们通过vim进入文件内部,看看它究竟是什么样子的:
果然如我们所料看不太懂,不知所云,这时候就借助我们老搭档gdb调试器的力量,输入指令:
gdb 可执行文件名 + 核心转储文件名
核心转储文件通过不同的可执行文件可能吐出不同的核,所以要带上可执行文件名,告诉操作系统这个核心转储文件是哪个可执行文件吐出的。