段错误(core dumped)

1 执行socket文件时，出现段错误 (core dumped产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问0地址.解决方法：利用gdb逐步查找段错误:首先我们需要一个带有调试信息的可执行程序，所以我们加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:1、 gcc -g -rdynamic d.c2、 gdb ./a.out3、 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文件最大为100kulimit -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、会提哪行有错。

应用程序运行时产生coredump故障处理环境：操作系统：AIX Common 数据库：无关应用程序：32-bit症状：客户应用结息程序在运行过程中产生coredump。

程序故障与处理数据量有关，当把结息网点分成两批，可以顺利完成。

解决方法：应用程序的问题本来不属于我们维保的范畴，因为客户关系比较好，开发商太极公司也是我们的友军，抱着试试看的态度来解决。

用svmon跟踪程序的执行，发现其在运行期间，work process private部分的内存增长速度非常快，并且很明显地，接近65536页的时候即发生core dump。

这表明程序故障与内存的过度使用有关，达到256MB阀值时溢出。

work process private与用户程序的堆、栈有关，其中堆常为malloc系统调用分配的内存空间。

这里与ulimit设置无关（已经设置为unlimited），与AIX 32位程序的内存分配行为有关。

32位程序最多可以使用16个内存段，其中segment 2~C用户可用作堆栈和共享内存，默认仅使用segment 2存放程序堆栈数据，最大值为256MB，所以默认情况下用户程序最多只能分配256MB的堆内存。

而这个默认行为，可以通过在执行程序前，设置LDR_CNTRL环境变量来调节堆栈部分和共享内存的比例，例如：LDR_CNTRL=MAXDATA=0x30000000，设置了堆栈内存空间最多可使用3个内存段，共768MB 内存。

下面是一个测试的例子：# include <stdio.h>main (){int i;unsigned char *p;i=0;while ( i < 20 ){printf ( "i=%d\n", i );/* 32M */p=(unsigned char *)malloc(33554432);memset(p,'\0',33554432);i=i+1;sleep(1);}sleep(120);}直接运行该程序，在i=7之后产生coredump，采用下面的方式执行命令：# LDR_CNTRL=MAXDATA=0x3000000 ./testmalloc程序能够正常执行结束运行，同时运行的svmon显示程序已经使用到了256MB以上的堆空间。

浅析Linux下core文件当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。

最常出现的，几乎所有C程序员都出现过的错误就是“段错误”了。

也是最难查出问题原因的一个错误。

下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。

何谓core文件当一个程序崩溃时，在进程当前工作目录的core文件中复制了该进程的存储图像。

core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。

当程序接收到以下UNIX信号会产生core文件：在系统默认动作列，“终止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，浮点溢出等。

达梦主备集群段错误（核⼼已转储）在给客户部署两套主备集群的时候，出现⼀件让我⾮常头疼的问题。

第⼀套集群在政务外⽹，第⼆套集群在互联⽹。

部署第⼀套集群的时候，启动达梦守护进程报错（段错误（核⼼已转储）），主备节点都报错，检查dm.ini 、 dmarch.ini 、 dmmal.ini和dmwatcher.ini，都没发现有任何错误。

这个时候我们猜测，会不会是安装包的问题，我们⽤的安装包如下：dm8_20210915_HWarm_centos7_64_ent_8.1.2.70.iso这是最新的安装包，我之前没⽤这个安装包部署过集群，猜测可能是安装包中有bug。

正好，在客户的第⼆套集群上试⼀下，看看会不会出现同样的问题。

吭哧吭哧部署完后，发现互联⽹上的那套集群，⼀切正常，这下傻眼了，检查了下集群配置，政务外⽹的和互联⽹的集群配置⼀模⼀样，那为什么政务外⽹那套集群会报错呢？接下来开始正式排查问题。

⼀、查看报错信息这是启动守护进程时报的错，从报错信息上看不出什么问题，后来也查看了watcher的⽇志，也没发现什么问题，最后只能⽣成core⽂件，查看core⽂件中的报错信息。

⼆、⽣成core⽂件集群出现问题，core⽂件⼀般会⾃动⽣成，可以直接查找对应的core⽂件，也可以指定core⽂件⽣成路径。

1、直接查找core⽂件因为我们是在启动dmwatcher的时候报错，所以可以直接通过守护进程的关键字进⾏查找。

1）、find查找find / -name *dmwatcher*查到的内容如下：2）、拷贝出来如果觉得直接在这⾥查看不⽅便，可以拷贝最新的core到指定⽬录，最好把名字重命名⼀下，默认的名称太长了。

cp拷贝出来拷贝最新的，⼀般最下⾯的⽐较新:cp /var/lib/systemd/coredump/core.dmwatcher.1001.88045ab03b7c437bb3b6ebbc53218cb6.16566.1631948801000000000000.lz4/home/dmdba/3）、Lz4解压lz4 core.dmwatcher.1001.88045ab03b7c437bb3b6ebbc53218cb6.16566.1631948801000000000000.lz44）、重命名mv core.dmwatcher.1001.88045ab03b7c437bb3b6ebbc53218cb6.16566.1631948801000000000000 core.165665）、查看core[root@localhost dmdba]# cd dmdbms/bin[root@localhost bin]# gdb /home/dmdba/core.16566输⼊bt6）、猜测core报错说“连接已存在”，猜测可能是ip和端⼝冲突导致的。

coredump文件生成过程
生成core dump文件通常发生在程序发生严重错误或崩溃时，
它记录了程序在崩溃时的内存状态和调用栈信息，有助于开发人员
分析问题并进行调试。

下面我会从多个角度来解释core dump文件
生成的过程。

1. 产生原因，当程序发生严重错误，比如访问非法内存、除零
错误、段错误等，操作系统会向程序发送一个信号，通常是SIGSEGV（段错误）或SIGABRT（异常终止），程序在收到信号后会
尝试生成core dump文件。

2. 操作系统设置，在大多数操作系统中，生成core dump文件
需要进行相应的设置。

在Linux系统中，可以使用ulimit命令设置core文件大小限制，使用sysctl命令设置core文件的名称格式和
存储路径。

在Windows系统中，可以通过控制面板中的系统属性进
行设置。

3. 内存转储，当程序接收到信号时，操作系统会将程序的内存
状态以及相关信息写入core dump文件中。

这包括程序的内存布局、寄存器状态、堆栈信息等。

4. 存储位置，生成的core dump文件通常会被存储在当前工作目录或指定的路径下，具体存储位置取决于系统设置和程序运行时的环境变量。

5. 调试分析，生成core dump文件后，开发人员可以使用调试工具（如gdb、windbg等）加载core dump文件，重现程序崩溃时的状态，并进行分析和调试，以找出程序中的错误和异常。

总的来说，生成core dump文件是程序在发生严重错误时的一种自我保护机制，它记录了程序崩溃时的状态信息，为开发人员提供了重要的调试和分析数据，有助于快速定位和解决问题。

SegmentFault（coredump）调试方法Coredump关于程序core dump的调试方法简述：首先，在程序不正常退出时，内核会在当前工作目录下生成一个core文件(是一个内存映像，同时加上调试信息)。

使用gdb来查看core文件，可以指示出导致程序出错的代码所在文件和行数。

这个能给debug带来极大方便。

查看core dump位置方法:"gdb ./app core".故，我们需要gdb，可执行文件app，以及core文件。

下面将根据这3个需求，依次得到它们;一、1,得到gdb;其实这个是最简单的，Linux PC上gdb不用说了。

Android的是~/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/b in/arm-linux-androideabi-gdb(其中~/opt/，与个人设置有关;android-ndk-r7与编译器版本有关,貌似android-ndk-r4没有toolchains目录，不知是否可以用gdbserver 调试程序，当然这就不在本文档的讨论范围之内了).2,得到可执行文件app由于要使用gdb，所以app必须是"not stripped".Linux PC上"gcc hello.c"编译出来的a.out默认就是"not stripped".Android工程中jni目录下，我们使用"ndk-build"默认是"stripped"的。

因此需要更改编译脚本：在~/opt/android-ndk-r7/build/core/中打开default-build-commands.mk文件，将"cmd-strip = $(PRIVATE_STRIP) --strip-unneeded $(call host-path,$1)"这一行注释掉.这一行就是做的"strip"操作。

coredump文件的生成方式
Core dump文件是在程序发生严重错误（如段错误、内存访问
越界等）时，操作系统将程序当前的内存状态以文件的形式保存下
来的一种机制。

生成core dump文件的方式可以通过以下几种途径：
1. 通过ulimit命令设置core dump文件大小限制，可以使用ulimit命令来设置core dump文件的大小限制，使用ulimit -c unlimited命令可以将core dump文件的大小限制设置为无限制，
这样当程序发生错误时就会生成core dump文件。

2. 在程序中使用系统调用设置，在程序中可以通过调用系统函
数来设置生成core dump文件的方式，比如使用ulimit函数设置core dump文件大小限制，或者使用prctl函数设置生成core dump
文件的路径等。

3. 通过操作系统的配置文件设置，在一些操作系统中，可以通
过修改配置文件（如/etc/security/limits.conf）来设置生成
core dump文件的大小限制和路径等参数。

4. 使用特定的调试工具，在调试程序时，可以使用特定的调试
工具（如gdb）来设置程序发生错误时生成core dump文件，通过gdb工具可以设置生成core dump文件的路径和大小限制等参数。

总的来说，生成core dump文件的方式可以通过操作系统的设置、程序中的系统调用、配置文件的修改以及调试工具的使用等途径来实现。

不同的操作系统和调试工具可能会有不同的设置方法，需要根据具体情况进行选择和配置。

C语⾔中段错误的解决⽅法Segmentationfault（coredumped）
在C语⾔中，任何操作指令都离不开对内存的操作，所以即便编译的时候没有语法操作，但是在实际运⾏中有可能对内存进⾏⾮法操作，这种情况就会产⽣段错误Segmentation fault (core dumped)！要解决段错误就要先找到段错误的地⽅。

如何在程序中寻找段错误？
段错误不是语法错误，所以在编译时不会提⽰出错，只有等到运⾏时才会提⽰出现段错误，但是段错误不会提⽰在哪⼀⾏，可以通过printf()函数来寻找段错误位置，只要发⽣段错误，那么程序就会马上结束。

举个例⼦：
printf("11111!\n");
xxxx;
printf("22222!\n");
yyyy;
printf("33333!\n");
zzzz;
假如运⾏上述代码得到的执⾏结果为：
11111!
22222!
Segmentation fault (core dumped) -> 说明段错误是出现"yyyy;"
段错误⼀般是指针指向有问题，找到段错误的地⽅最好打印出指针内容看看是不是⾃⼰预期的指针内容再进⾏修改，如果是链表就画图查看⾃⼰的链表逻辑有没有出问题
总结解决段错误的步骤：
1.使⽤printf()函数寻找段错误的地⽅
2.打印出现段错误的指针，链表或者打开⽂件⽬录的返回值看看是不是⾃⼰的预期结果
3.根据结果现在修改代码重新编译。

Segmentationfault（coredumped）错误的⼀种解决场景错误类型Segmentation fault (core dumped)产⽣原因Segmentation fault 段错误。

Core Dump 核⼼转储（是操作系统在进程收到某些信号⽽终⽌运⾏时，将此时进程地址空间的内容以及有关进程状态的其他信息写出的⼀个磁盘⽂件。

这种信息往往⽤于调试），其实“吐核”这个词形容的很恰当，就是核⼼内存吐出来。

出现这种错误可能的原因（其实就是访问了内存中不应该访问的东西）：1，内存访问越界：（1）数组访问越界，因为下标出超出了范围。

（2）搜索字符串的时候，通过字符串的结尾符号来判断结束，但是实际上没有这个结束符。

（3）使⽤strcpy, strcat, sprintf, strcmp,strcasecmp等字符串操作函数，超出了字符中定义的可以存储的最⼤范围。

使⽤strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防⽌读写越界。

2，多线程程序使⽤了线程不安全的函数。

3，多线程读写的数据未加锁保护。

　对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成核⼼转储4，⾮法指针（1）使⽤NULL指针（2）随意使⽤指针类型强制转换，因为在这种强制转换其实是很不安全的，因为在你不确认这个类型就应该是你转化的类型的时候，这样很容易出错，因为就会按照你强制转换的类型进⾏访问，这样就有可能访问到不应该访问的内存。

5，堆栈溢出不要使⽤⼤的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。

解决场景在linux的虚拟机上跑了⼀个数据结构，在虚拟机上出现上述错误，在Windows的宿主机弹出错误。

于是试运⾏⼀个相似的较简单的哈希函数，虚拟机上出现相同错误，，注意到以下代码：// generates a hash value for a sting// same as djb2 hash functionunsigned int CountMinSketch::hashstr(const char *str) {unsigned long hash = 5381;int c;while (c = *str++) {hash = ((hash << 5) + hash) + c; /* hash * 33 + c */}return hash;}这是⼀个针对字符串的哈希函数，其中⼀⾏hash = ((hash << 5) + hash) + c; /* hash * 33 + c */是问题所在，针对较长的字符串，这个hash变量会不断变⼤，甚⾄溢出。

Linux下的段错误产生的原因及调试方法&&Core Dump简而言之,产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问0地址.一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gdtr来保存的，他是一个48位的寄存器，其中的32位是保存由它指向的gdt表，后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表，在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。

一旦一个程序发生了越界访问，cpu就会产生相应的异常保护，于是segmentation fault就出现了.在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的1)访问系统数据区，尤其是往系统保护的内存地址写数据最常见就是给一个指针以0地址2)内存越界(数组越界，变量类型不一致等) 访问到不属于你的内存区域解决方法我们在用C/C++语言写程序的时侯，内存管理的绝大部分工作都是需要我们来做的。

实际上，内存管理是一个比较繁琐的工作，无论你多高明，经验多丰富，难免会在此处犯些小错误，而通常这些错误又是那么的浅显而易于消除。

但是手工“除虫”（debug），往往是效率低下且让人厌烦的，本文将就"段错误"这个内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。

作地址为0的内存区域，而这个内存区域通常是不可访问的禁区，当然就会出错1.利用gdb逐步查找段错误:这种方法也是被大众所熟知并广泛采用的方法，首先我们需要一个带有调试信息的可执行程序，所以我们加上“-g -rdynamic"的参数进行编译，然后用gdb调哦？！如此的简单。

从这里我们还发现进程是由于收到了SIGSEGV信号而结束的。