linux下，gcc提示“段错误 (核心已转储)”，ubuntu刚上手不大会用，谁说一下是什么问题

Posted 2023-05-03

fscan的问题

主要有以下几个方面的原因：

一、内存访问出错

这类问题的典型代表就是数组越界。

二、非法内存访问

出现这类问题主要是程序试图访问内核段内存而产生的错误。

三、栈溢出

Linux默认给一个进程分配的栈空间大小为8M。c++申请变量时，new操作申请的变量在堆中，其他变量一般在存储在栈中。

因此如果数组开的过大变会出现这种问题。

扩展资料：

注意事项

段错误一般就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gdtr来保存的，他是一个48位的寄存器，其中的32位是保存由它指向的gdt表，后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别，指向的gdt是由以64位为一个单位的表，在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。

一旦一个程序发生了越界访问，cpu就会产生相应的异常保护，于是segmentation fault就出现了。在编程中基本是是错误地使用指针引起的。

参考技术A

出现此问题的原因如下：

1、内存访问错误

这种问题的典型代表是数组越界。

2、非法内存访问

这种问题主要是由程序尝试访问内核段内存的错误引起的。

3、堆栈溢出

默认情况下，Linux为进程分配8M的堆栈空间。 当C ++申请变量时，新申请的变量在堆中，而其他变量通常存储在堆栈中。

因此，如果数组太大，则会出现此问题。

扩展资料：

段故障通常意味着访问的内存超出了系统为程序分配的内存空间。 通常，此值由gdtr存储，是一个48位寄存器，其轨道中的32位由其存储。 

gdt表，后13位保存与gdt对应的下标，后3位包括程序是否在内存中以及cpu中程序的运行级别，gdt指向的表是一个以64位为单位的表。在此表中，代码段的信息和数据段的起始地址，相应的段限制和页交换，程序运行级别和内存粒度存储在该表中。

一旦对程序进行越界访问，CPU将生成相应的异构保护，并且将出现分段错误。 基本上，这是由于编程中不正确使用指针引起的。

参考技术B linux系统为一个进程的分配的堆栈空间只有8k左右，你定义了一个300万的整形数组，需要占用3000000*4=1200万k大小的堆栈空间，肯定会把堆栈撑爆的，故会出现核心已转储的错误提示。

为了提高程序的健壮性，防止堆栈越界的情况发生，一般局部变量分配的空间不要超过1024字节大小，就是一个255的整形数组。如果你想要用超过1024字节以上的空间，就调用malloc在堆中分配你想要的空间。 参考技术C 大概是堆栈溢出，3百万个指针的数组太大了，占地12M（32位机器），24M（64bit）。
想确认请在终端输入 ulimit -s，查看堆栈限制。
想无视堆栈限制，请尝试ulimit -s unlimited 参考技术D segmentation fault(core dump)
你写的代码有严重bug，导致程序崩溃

core dump

前言

段错误（核心已转储）！！！

# ./test.out 
Segmentation fault (core dumped)

$ ./core.out 
段错误 (核心已转储)

运行一个程序，不小心发生了 段错误（核心已转储），多悲催啊😆。幸好我们有 core dump，能够帮助调试程序崩溃问题。今天我们就来聊一聊 core dump。

概述

core dump 一词来源于 magnetic-core memory，这是上世纪六七十年代主流的内存介质。core 指记忆体也就是现在的内存。
操作系统在进程收到某个信号而终止运行时，将此时进程地址空间的内容以及进程相关状态信息写入一个磁盘文件，这个过程就叫 core dump，产生的文件就叫 core 文件。
core dump 记录了程序崩溃时的案发现场。我们可以使用 gdb 对 core 文件进行分析，叫做现场还原，就能够看到程序是因何而崩溃。

前提条件

a) 需要事先开启 core dump 功能，使用如下命令

ulimit -c 1024

b) gcc 编译程序需要加上 -g 选项以增加调试信息。

测试环境

BananaPi M1（在 ubuntu 上始终无法生成 core 文件，知道方法的同学可以留言）

测试程序

test.c

#include <stdio.h>

int main(int argc, char argv) 

	int *p = NULL;

	*p = 0; 	// 给空指针指向的地址赋值，引发core dump

	return 0;

编译

$ /home/liyongjun/project/board/buildroot/BPi-M1/host/bin/arm-buildroot-linux-uclibcgnueabihf-gcc -g test.c -o test.out

core dump

在 BananaPi M1 上运行

# ./test.out 
Segmentation fault
# ulimit -c 1024
# ./test.out 
Segmentation fault (core dumped)
# ls
core   test.out

第一次运行，发现并没有出现 core dump，是因为没使能 core dump 功能，使用 ulimit -c 1024 使能后，就出现了 core dump，ls 能看到 core 文件。

gdb 分析

上传到 ubuntu 使用 gdb 分析

$ arm-linux-gnueabihf-gdb test.out core 
GNU gdb (Linaro_GDB-2017.08) 8.0.0.20170823-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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 "--host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test.out...done.
[New LWP 149]

warning: Could not load shared library symbols for 2 libraries, e.g. /lib/libc.so.0.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `./test.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x004e15a0 in main (argc=1, argv=116 't') at test.c:7
7		*p = 0; 	// 给空指针指向的地址赋值，引发core dump
(gdb)

gdb 直接就定位到了崩溃点：第 7 行：*p = 0;。