core dump的生成与调试

本文介绍如何在Linux环境下配置系统以生成core文件,并通过GDB进行调试的过程。包括调整ulimit设置、触发core dump及分析core文件中的程序崩溃原因。

在Linux下产生并调试core文件

URL: http://blog.china-pub.com/more.asp?name=uniware&id=35478

先看看我用的是个什么机器:

$ uname -a
Linux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux

再看看默认的一些参数,注意core file size是个0,程序出错时不会产生core文件了。

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

写个简单的程序,看看core文件是不是会被产生。

$ more foo.c

#include <stdio.h>

static void sub(void);

int main(void)
{
sub();
return 0;
}

static void sub(void)
{
int *p = NULL;

/* derefernce a null pointer, expect core dump. */
printf("%d", *p);

}

$ gcc -Wall -g foo.c
$ ./a.out
Segmentation fault

$ ls -l core.*
ls: core.*: No such file or directory

没有找到core文件,我们改改ulimit的设置,让它产生。1024是随便取的,要是core文件大于1024个块,就产生不出来了。

$ ulimit -c 1024 (转者注: 使用-c unlimited不限制core文件大小)

$ ulimit -a
core file size (blocks, -c) 1024
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

$ ./a.out
Segmentation fault (core dumped)
$ ls -l core.*
-rw------- 1 uniware uniware 53248 Jun 30 17:10 core.9128

注意看上述的输出信息,多了个(core dumped) 。确实产生了一个core文 件,9128是该进程的PID。我们用GDB来看看这个core。

$ gdb --core=core.9128 (gdb -c corefile execfile)
GNU gdb Asianux (6.0post-0.20040223.17.1AX)
Copyright 2004 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 certain conditions.
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-asianux-linux-gnu".
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048373 in ?? ()
(gdb) bt
#0 0x08048373 in ?? ()
#1 0xbfffd8f8 in ?? ()
#2 0x0804839e in ?? ()
#3 0xb74cc6b3 in ?? ()
#4 0x00000000 in ?? ()

此时用bt看不到b ackt race,也就是调用堆栈,原来GDB还不知道符号信息在哪里。我们告诉它一下:

(gdb) file ./a.out
Reading symbols from ./a.out...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) bt
#0 0x08048373 in sub () at foo.c:17
#1 0x08048359 in main () at foo.c:8


此时backtrace出来了。

(gdb) l
8 sub();
9 return 0;
10 }
11
12 static void sub(void)
13 {
14 int *p = NULL;
15
16 /* derefernce a null pointer, expect core dump. */
17 printf("%d", *p);

<think>我们已经在之前的回答中详细说明了如何永久修改core dump文件大小限制。现在用户的新问题是:如何测试core dump文件的生成机制?即如何模拟程序崩溃以生成core dump文件,从而验证配置是否生效。 根据用户提供的引用[1]和引用[2],我们了解到: 1. 当进程接收到某些信号(如SIGSEGV, SIGABRT等)时,会触发core dump生成。 2. 需要确保core dump功能已开启(通过ulimit -c检查)且路径可写。 因此,测试步骤应包括: 1. 确保已配置core dump生成(如通过ulimit -c unlimited)。 2. 编写一个会崩溃的程序(如触发段错误)或使用命令模拟崩溃。 3. 运行程序,检查是否在预期位置生成core dump文件。 具体测试方法如下: ### 测试方法1:使用简单C程序触发段错误 ```c // 文件名:test_core.c #include <stdio.h> int main() { int *p = NULL; *p = 42; // 对空指针解引用,触发段错误 return 0; } ``` 编译并运行: ```bash gcc -g test_core.c -o test_core # 编译时加入调试信息 ./test_core # 运行程序,应产生段错误 ls -l ./core.* # 检查当前目录下的core文件(取决于core_pattern配置) ``` ### 测试方法2:使用Shell命令模拟崩溃 ```bash # 方法1:使用kill命令发送信号 sleep 100 & # 后台运行一个长时间进程 kill -SIGSEGV $! # 向该进程发送段错误信号 # 方法2:使用bash内置命令触发段错误 kill -SEGV $$ # 向当前shell进程发送信号(会终止当前shell) # 或者更安全的方式(在子shell中运行): ( kill -SEGV $$ ) # 在子shell中触发,避免影响当前shell ``` ### 测试方法3:使用Python脚本 ```python # 文件名:test_core.py import os import signal os.kill(os.getpid(), signal.SIGSEGV) # 向自身发送段错误信号 ``` 运行: ```bash python3 test_core.py ``` ### 验证core dump文件生成 - 检查core_pattern配置的目录(默认可能是当前目录或/var/lib/systemd/coredump) ```bash cat /proc/sys/kernel/core_pattern ``` - 使用coredumpctl工具(systemd系统): ```bash coredumpctl list # 列出所有core dump ``` ### 注意事项 1. 确保程序崩溃时的工作目录有写入权限(或core_pattern指定的目录)。 2. 如果使用`sudo`运行程序,core文件可能生成在root的家目录。 3. 测试前确保core dump已开启(`ulimit -c unlimited`在当前终端生效)。 ### 测试步骤总结 1. 配置core dump(如`ulimit -c unlimited`或通过永久配置)。 2. 编写或选择一种方法触发崩溃。 3. 运行程序,观察是否生成core文件。 4. 使用调试工具(如gdb)分析core文件,验证其有效性: ```bash gdb ./test_core core.pid # 使用gdb加载core文件 (gdb) bt # 查看堆栈回溯 ``` §§相关问题§§ 1. 如何分析core dump文件以定位程序崩溃原因? 2. 为什么有时候程序崩溃了却没有生成core dump文件? 3. 如何配置core dump文件名称包含进程名和时间戳? 4. 在多线程程序中,core dump会记录所有线程的信息吗?</think>### 测试 core dump 文件生成机制的方法 以下是验证 core dump 生成机制的完整测试流程,包含多种测试场景: #### 📝 测试准备 ```bash # 1. 确保 core dump 功能已启用 ulimit -c unlimited # 临时解除限制 echo "/tmp/core-%e-%p-%t" | sudo tee /proc/sys/kernel/core_pattern # 设置生成路径 # 2. 安装调试工具 sudo yum install gdb -y # CentOS sudo apt install gdb -y # Ubuntu ``` #### ⚙️ 测试方法 1:直接触发崩溃(推荐) ```bash # 创建测试程序 (C语言) cat << EOF > test_core.c #include <stdio.h> int main() { int *p = NULL; *p = 42; // 故意解引用空指针 return 0; } EOF # 编译并运行 gcc -g test_core.c -o test_core ./test_core # 应产生段错误 SIGSEGV # 验证 core dump ls -lh /tmp/core-test_core* # 检查生成文件 ``` #### ⚙️ 测试方法 2:使用 kill 命令模拟 ```bash # 启动后台进程 sleep 1000 & PID=$! # 发送崩溃信号 kill -SIGSEGV $PID # 模拟段错误 kill -SIGABRT $PID # 模拟断言失败 # 检查生成结果 coredumpctl list $PID # systemd 系统 ls /tmp/core-sleep* # 传统系统 ``` #### ⚙️ 测试方法 3:Python 脚本测试 ```python # test_core.py import os, signal os.kill(os.getpid(), signal.SIGSEGV) # 自毁信号 ``` ```bash python3 test_core.py ls /tmp/core-python* ``` #### 🔍 验证分析 ```bash # 1. 检查文件生成 file /tmp/core-test_core* # 应显示 "ELF core dump" # 2. 使用 GDB 分析 gdb ./test_core /tmp/core-test_core* (gdb) bt # 查看调用栈 (gdb) info registers # 检查寄存器状态 ``` #### 🧪 测试场景矩阵 | 测试场景 | 触发方式 | 预期信号 | 验证方法 | |--------------------------|---------------------------|------------|------------------------| | 空指针解引用 | `*NULL = value` | SIGSEGV | GDB 查看崩溃地址 | | 除零错误 | `int x=1/0;` | SIGFPE | 检查算术异常 | | 非法指令 | `asm("ud2");` | SIGILL | 反汇编验证 | | 内存越界 | `buffer[1000]=0` (小数组) | SIGSEGV | AddressSanitizer 工具 | | 主动终止 | `abort()` | SIGABRT | 检查断言消息 | | 总线错误 | 未对齐内存访问 | SIGBUS | 架构相关测试 | #### ⚠️ 常见问题排查 1. **无 core 文件生成**: - 检查 `ulimit -c` 是否返回 `unlimited` - 确认 `cat /proc/sys/kernel/core_pattern` 路径可写 - 检查磁盘空间 `df -h /tmp` 2. **文件权限问题**: ```bash sudo sysctl -w kernel.core_uses_pid=1 # 添加 PID 到文件名 sudo sysctl -w fs.suid_dumpable=2 # 允许 setuid 程序生成 ``` 3. **容器环境测试**: ```bash docker run --ulimit core=-1 -it alpine sh -c "sleep 10 & kill -ABRT $!" ``` > 📌 测试提示:使用 `coredumpctl debug` 可直接调试最新生成core 文件[^1]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值