[skill][gdb][coredump][abrt] 使用abrt管理程序coredump

最新推荐文章于 2024-12-12 10:57:37 发布

转载最新推荐文章于 2024-12-12 10:57:37 发布 · 581 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/hugetong/p/8042653.html

abrt：Automatic bug detection and reporting tool

https://github.com/abrt/abrt

常用的命令：

abrt-auto-reporting

abrt-cli

配置文件：

/etc/abrt/abrt.conf

/etc/abrt/abrt-action-save-package-data.conf

一般来讲，abrt直接就能用，直接就能查看coredump信息。

但是，当处理我们自己写的程序时，仍然不能用。

关系到下面的两个配置

abrt.conf: MaxCrashReportsSize = 1000

关系到crash信息文件的大小，最大的就是coredump，coredump太大可能就不会存，或者存的少？

反正，把它设成0,就相当与 ulimit -c unlimited

abrt-action-save-package-data.conf: ProcessUnpackaged = yes

我们自己写的可执行程序，一般就是拷过去的，不从属于任何的package（rpm？），所有abrt不生效，可以见到如下log信息：

Dec 12 09:26:19 T185 abrt-server: Executable '/anthropoid/bin/msg_unpack.py' doesn't belong to any package and ProcessUnpackaged is set to 'no'

可以将这个选项设置成 yes。

这样的话，就可以在程序coredump的时候，使用abrt找到coredump文件了。而并不用修改ulimit参数

[root@T185 ~]# abrt-cli ls
id 821a267b8fe28bdbb8b8aa546838f630ff42270a
reason:         chimpanzee killed by SIGSEGV
time:           Fri 15 Dec 2017 11:44:53 AM CST
cmdline:        chimpanzee
uid:            0 (root)
count:          1
Directory:      /var/spool/abrt/ccpp-2017-12-15-11:44:53-11380

The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges
[root@T185 ~]#

转载于:https://www.cnblogs.com/hugetong/p/8042653.html

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

weixin_30341735

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

linux abrt的用法

笔者从事电信媒体开发多年，愿意将多年的开发经验分享给同行

11-12

3万+

abrt-cli core

【0251】如何让pg生成core文件，并通过gdb工具定位到pg服务异常崩溃点（精确到函数行）

Postgres 数据库内核开发工程师

01-25

772

一些不经意的因素、操作，总会让PostgreSQL服务异常崩溃。这些报错日志都意味着pg服务异常崩溃停止了（问题很严重）。而pg的log文件往往只有这些简单的提示打印，仅依赖这些提示，是无法定位到具体问题所在的。除非你精通pg源码，所有源码滚瓜烂熟；很显然，是无法做到这一点的。那么面对这样的崩溃问题，要如何去定位崩溃原因，是一个比较困难的话题。如果有方法能够找到崩溃根源，且精确到pg源码中的某个函数的某一行，那可就太棒了。本文内容是作者多年下来总结出的经验，真实可靠、有效。

参与评论您还未登录，请先登录后发表或查看评论

linux abrt 输出目录,linux – 如何从`abrt`获得coredump

weixin_35123329的博客

04-28

548

我正在运行Fedora 23,刚刚发现abrt处理崩溃的应用程序中的coredump,并将所有类型的东西放在/ var / spool / abrt / ccpp-date-pid中.是否有命令从abrt获取coredump,而不从指定的文件夹手动复制它？或者我可以abred将coredump提供给gdb,还加载二进制文件？我宁愿不改变/ proc / sys / kernel / core_pa...

3-11·RHEL7&CentOS7服务命令

12-19

955

1）服务状态1.检查服务器服务状态[root@lee ~]# systemctl -t service UNIT LOAD ACTIVE SUB DESCRIPTION abrt-ccpp.service loaded active exited Install ABRT c

关于Linux的core dump

weixin_33971130的博客

01-21

477

core dump简介 core dump就是在进程crash时把包括内存在内的现场保留下来，以备故障分析。但有时候，进程crash了却没有输出core，因为有一些因素会影响输出还是不输出core文件。常见的一个coredump开关是ulimit -c，它限制允许输出的coredump文件的最大size，如果要输出的core文件...

Android——coredump解析

weixin_30786657的博客

05-15

645

撰写不易,转载需注明出处：http://blog.youkuaiyun.com/jscese/article/details/46916869本文来自【jscese】的博客！ coredump文件生成前文Android——coredump 配置记录了android平台上的环境配置，生成方式正常即为process触发那几种signal 手动coredump状态：连接gdb -gcore pid终端发送...

linux abrt进程,关于Linux的core dump

weixin_31689491的博客

04-28

3073

core dump简介core dump就是在进程crash时把包括内存在内的现场保留下来，以备故障分析。但有时候，进程crash了却没有输出core，因为有一些因素会影响输出还是不输出core文件。常见的一个coredump开关是ulimit -c，它限制允许输出的coredump文件的最大size，如果要输出的core文件大小超过这个值将不输出core文件。ulimit -c的输出为0，代...

【无脑教程】Fedora & CentOS下coredump文件生成方法

康康的博客

05-19

3351

背景测试环境 Fedora 25&24 CentOS 7 目测 Deepin 并没有坑而Ubuntu可能也存在这个问题(也有类似abrt的二进制文件)前言从Windows平台下转到到Linux下的C/C++开发可能第一个接触到的新名词就是段错误也就是这样首先是一段神秘代码#include <stdio.h> int main(void) { char a[1]; char

关于javacore和dump文件

牧夏的个人博客

01-04

1万+

Dump 就是对程序运行时内存上的信息进行转储, 让我们可以查看程序当时的运行情况. Dump 对于调优和排错是非常有用的工具. Heap Dump Java 运行时对象分配在堆内存上, Heap dump 就是对堆内存进行转储. 生成 jmap 通过命令jmap -dump:live,format=b,file=***.hprof pid eg:jmap -dump:live,format=b,...

gdb调试java_gdb调试core分析jvm（JNI）奔溃原因

weixin_29482557的博客

03-06

1116

前几天服务(服务中使用了JNI调用了C++的so库)在并发测试几天后jvm突然奔溃，只在控制台打印出了一句话： terminate called after throwing an instance of ‘._0’。因为只根据这句话无法确定奔溃原因，于是查看linux系统日志，进入/var/log下，打开message文件，看到下面的话：Sep 16 13:44:04 localhost abr...

coredump 续---abort，addr2line

3-Number

06-06

2420

0x01缘由在项目实际开发中，当出现段错误时，为了定位问题的代码行。必须保留程序运行上下文、根据linux内核日志定位代码行等。有时当程序自己发现问题时，自动退出程序释放资源，如发现系统内存耗尽时，退出程序，又得自动将文件流刷新到磁盘等。 0x02 abort介绍信号量：SIGABRT 6 程序自己发现错误并调用 abort 时产生。

服务器系统abrt无法生成core文件

Asen的博客

12-12

316

安装了abrt用于自动错误报告，但系统无法生成core文件

Linux下coredump使用

一朵花开的时间

07-16

1270

01 什么coredump 当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中（core文件），这种行为就叫做 Core Dump 或者叫做"核心转储"，利用 coredump 可以帮助我们快速定位程序崩溃位置。通常情况下，core文件会包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息还有各种函数调用堆栈信息等，我们可以理解为是程序工作当前状态存储生成的一个文件，许多的程序出错的时候都会产生一个core文件，通过工具分析这个文件，我们可以定位到程序异常退出

Linux Coredump 设置

wqfhenanxc的专栏

09-06

1378

一. 查询core dump文件路径：方法1： # cat /proc/sys/kernel/core_pattern 方法2： # /sbin/sysctl kernel.core_pattern 二. 修改core dump文件路径：方法1：临时修改：修改/proc/sys/kernel/core_pattern文件，但/proc目录本身是动态加载的，每次系统重启都会重新加载，因此这种...

linux abrt进程,Linux进程及作业控制

weixin_34208121的博客

04-28

770

inux进程进程的概念当一个系统启动时，刚开机是第一个运行的是内核代码！先把内核放到cpu上运行，等内核控制和掌管了一切，有内核启动进程！然后创建第一个进程init进程内核空间用户空间也都已被创建成功！后期的一切管理工作都由init来负责init不能代表系统完成一些内核特权的执行！但由他负责向内核提交他是总的由用户管理的总进程，它会照自己样子创建一个子进程，除了init以外，所有的进程都是...

报错：ABRT 已检测到 ‘1‘ 个问题。预了解详细信息请执行：abrt-cli list --since 1653881497

最新发布

07-22

<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]