如何排查大型C程序中的内存写越界导致的coredump

通常情况下coredmp包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息等。可以理解为把程序工作的当前状态存储成一个文件。许多程序和 *** 作系统出错时会自动生成一个core文件。

内存访问越界

a) 由于使用错误的下标，导致数组访问越界

b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符

c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串 *** 作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。

当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。最常出现的，几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们如何利用core文件找到出现崩溃的地方。

core文件创建在什么位置

在进程当前工作目录的下创建。通常与程序在相同的路径下。但如果程序中调用了chdir函数，则有可能改变了当前工作目录。这时core文件创建在chdir指定的路径下。有好多程序崩溃了，我们却找不到core文件放在什么位置。和chdir函数就有关系。当然程序崩溃了不一定都产生core文件。

什么时候不产生core文件

在下列条件下不产生core文件：

( a )进程是设置-用户-ID，而且当前用户并非程序文件的所有者；

( b )进程是设置-组-ID，而且当前用户并非该程序文件的组所有者；

( c )用户没有写当前工作目录的许可权；

( d )文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写，组读和其他读。

利用GDB调试core文件，当遇到程序崩溃时我们不再束手无策。

如果用CMake编译工程，则使用选项CMAKE_BUILD_TYPE=Debug：

这样做g++编译时就会包含选项-g。如果要同时包含-ggdb选项，可以设置变量CMAKE_CXX_FLAGS_DEBUG。

%e - insert coredumping executable name into filename 添加导致产生core的命令名

%p - insert pid into filename 添加pid(进程id)

运行程序，生成core文件。下面的命令强制生成core文件：

或者进入gdb后

file从文件exec加载symbol和executable, core从core中加载coredump

如果是调试Core的机器（host）不是生成Core的机器（target），则动态库可能不在程序指定的位置上。这时需要指定动态库的位置。

首先用info sharedlibrary，可以查看动态库的symbol是否加载正确

如果库在host上的布局与在target上的布局相同，则使用solib-absolute-prefix比较方便。

target上：

host上：

则可以设置solib-search-path为：

solib-absolute-prefix有个更常用的别名sysroot，所以如下的命令是一样的：

设置solib-search-path可以指定多个路径，路径之间用:隔开。

在多线程的环境下，可以用info threads显示所有线程，thread指定线程为当前线程。

GDB 常用法

GDB 调试Coredump问题

嵌入式开发中GDB调试Coredump问题

嵌入式开发中GDB串口远程调试

用backtrace()调试coredump问题

Valgrind memcheck 用法

Address Sanitizer 用法

段错误及GDB Coredump调试方法

https://blog.csdn.net/oscarjulia/article/details/74256997

gdb调试多进程与多线程

https://blog.csdn.net/snow_5288/article/details/72982594

---