gdb强行生成core文件

最新推荐文章于 2024-05-02 18:51:02 发布
原创 最新推荐文章于 2024-05-02 18:51:02 发布 · 1.4w 阅读 · 13 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

调试卡死的时候，有时需要杀死进程重启后再分析原因，这时候需要先把卡死状态保持起来，生成core文件，重启后慢慢分析。

1、gcore

usage:  gcore [-o filename] pid

用法如下：

[root@htdev ~]# gcore 19388 
[Thread debugging using libthread_db enabled]
[New Thread 0x2b46ed999890 (LWP 19388)]
[New Thread 0x43e62940 (LWP 19399)]
[New Thread 0x43461940 (LWP 19398)]
[New Thread 0x42a60940 (LWP 19397)]
[New Thread 0x4205f940 (LWP 19396)]
[New Thread 0x41018940 (LWP 19390)]
[New Thread 0x41007940 (LWP 19389)]
0x000000364b4d06d9 in syscall () from /lib64/libc.so.6
Saved corefile core.19388

2、gdb的generate-core-file命令

[root@htdev ~]# gdb attach 19388
或者[root@htdev ~]# gdb -q - 19388
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 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 "x86_64-redhat-linux-gnu"...
attach: No such file or directory.
Attaching to process 19388
Reading symbols from /usr/local/bin/node...done.
Reading symbols from /lib64/librt.so.1...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/libstdc++.so.6...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x2b46ed999890 (LWP 19388)]
[New Thread 0x43e62940 (LWP 19399)]
[New Thread 0x43461940 (LWP 19398)]
[New Thread 0x42a60940 (LWP 19397)]
[New Thread 0x4205f940 (LWP 19396)]
[New Thread 0x41018940 (LWP 19390)]
[New Thread 0x41007940 (LWP 19389)]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /root/eicn/work/web/node_modules/hiredis/build/Release/hiredis.node...done.
Loaded symbols for /root/eicn/work/web/node_modules/hiredis/build/Release/hiredis.node
0x000000364b4d06d9 in syscall () from /lib64/libc.so.6
(gdb) generate-core-file
Saved corefile core.19388
(gdb) detach
Detaching from program: /usr/local/bin/node, process 19388

3、修改生成core大小

使用ulimit -a查看当前情况，ulimit -c只查看core文件大小

[root@htdev ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16383
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 16383
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[root@htdev ~]# ulimit -c
0

使用ulimit -c filesize命令，可以限制core文件的大小（filesize的单位为kbyte）。若ulimit -c unlimited，则表示core文件的大小不受限制。如果生成的信息超过此大小，将会被裁剪，最终生成一个不完整的core文件。在调试此 core文件的时候，gdb会提示错误。

[root@htdev ~]# ulimit -c unlimited


4、设置core文件路径 

1.编辑环境配置文件，让shell启动时自动设置ulimit
2.更改core文件生成路径
3.sysctl配置生效
vi /etc/profile
ulimit -c unlimited > /dev/null 2>&1
vi /etc/sysctl.conf
kernel.core_uses_pid = 1
kernel.core_pattern=/tmp/core-%e-%p
sysctl -p /etc/sysctl.conf





GDB：产生core文件
风静如云的博客
05-28 2833
core文件是调试段错误的重要手段，默认情况下是不会生成core文件的，可通过如下方式对生成core文件进行设置： 1.打开core开关 可以先通过ulimit -c，进行查看，如果输出为0，表示不会生成core文件 可以通过ulimit -c[filesize] 或ulimit -cunlimited对core文件的大小进行设置 如果希望每次打开bash这个设置都处于生效状态，可以把ulimit -c unlimited写入bash配置文件：~/.bashrc 2.core文件的生成位置...
gdb强制生成core文件
thebestismin的专栏
01-06 519
gdb生成core文件
GDB快速的生成一个core
weixin_34362991的博客
09-18 242
gdb快速的生成一个core经常会遇到问题，想从堆栈去查看信息，那么快速的生成一个core是一个首要问题。gdb挂在程序上，设置断点后，使用gdb的generate-core-file命令，就可以快速生成一个core。如果当时不能定位问题，将该core和对应的程序一起保存。可以方便以后再查看原因。 转载于:https://blog.51cto...
GDB再学习（11）：如何生成Core文件
Stoneshen的博客
10-07 3362
文章目录1 确认core文件开关是否开启2 修改core生成路径和文件格式 前面简单介绍了GDB相关的调试经验，但是在资源有限的嵌入式设备中，很难跑的了GDB ,因此就需要程序异常时候生成的core文件来解析程序的堆栈信息，这时候就需要对linux系统进行一些设置，用于程序异常时候可以生成core文件。 1 确认core文件开关是否开启 我们输入指令ulimit -a # ulimit -a core file size (blocks, -c) 0 data seg size
生成分析core文件
weixin_42447367的博客
03-15 843
目录core文件作用如何生成分析core文件相关配置生成core文件用gdb分析core文件 core文件作用 通常在 Linux 下遇到程序异常退出或者中止，我们都会使用 core 文件进行分析，其中包含了程序运行时的内存，寄存器，堆栈指针等信息，格式为 ELF ，可以理解是程序工作当前状态转储成一个文件，通过工具分析这个文件，我们可以定位到程序异常退出或者终止时相应的堆栈调用等信息，为解决问题提供帮助。 如何生成分析core文件 相关配置 检查core文件是否打开：ulimit -a 阻止core文件
linux下gdb调试和coredump内核转储
hallyz的博客
05-26 1093
1、GDB简介   GDB（GNU Debugger）是一个由GNU开源组织发布的、UNIX/LINUX操作系统下的、基于命令行的、功能强大的程序调试工具。是linux系统环境下的C/C++开发者必须掌握的一个开发工具。 2、 GDB调试流程 2.1 准备 这里用c程序做演示； #include <stdio.h> int main() { printf("enter main()\n"); int i = 0; for(; i<10; i++){ pri
linux手动生成dump文件权限不足_Linux下c/c++开发之程序崩溃(Segment fault)时内核转储文件(core dump)生成设置方法...
weixin_39757626的博客
12-22 660
Linux下c/c++开发之程序崩溃(Segment fault)时内核转储文件(core dump)生成设置方法 Linux下c/c++开发程序崩溃(Segment fault)通常都是指针错误引起的.以下是我们详细的对Linux core dump的调试技术进行的介绍: Linux core dump简介有的程...Linux下c/c++开发之程序崩溃(Segment fault)时内核转储文...
如何给有死锁的进程发送信号，让他产生core文件
烟花易冷
08-01 2933
当然就是没有死锁也可以发信号让他产生core文件 1 首先来了解信号 Signal Description Signal number on Linux x86[1] SIGABRT Process aborted 6 SIGALRM Signal raised by alarm 14 SIGBUS Bus error: "access to undefined
GDB调试 多线程 进程 coredump
qq_23141637的博客
10-28 2140
1、调试简单多线程 学习：【Linux】gdb调试多线程与多进程 GDB 调试多线程程序的总结 gdb调试多进程与多线程 生成程序 gcc -o env threadgdb1.c -lpthread -g #include <stdio.h> #include <pthread.h> #include <stdlib.h> #include <unistd.h> static int count = 0; void *pthread_fuc(void *ar
linux下vim、gcc、gdb的使用
weixin_45897952的博客
03-05 1877
1、包安装包：yum 1.1要安装vim首先我们要知道一个工具yum,yum就是一个应用商店，类似于华为商店，苹果商店等等，里面有经过yum源认证的软件安装包。如果程序员想要那个软件包，就可以使用yum搜索和安装。由于是从yum源下载到本地进行安装，所以必须要有 ...
generate core file with gdb
贾亮的专栏
09-11 1322
gdb attach pid generate-core-file http://prefetch.net/blog/index.php/2006/12/21/generating-core-files-from-gdb/
gdb生成core文件
开发笔记
09-24 882
1，首先，通过 ps-ef 命令查找pid进程号 由图可知，我所要查找的mvp进程，它的进程号为8114 第二步：输入gdb命令 第三步：输入， ‘attach 8114’命令将gdb附加到进程8114上 第四步：使用gcore core_name 生成coredump文件 core_name 第五步：使用detached断开连接 第六步：输入q命令
gdb调试生成core文件 快速定位
z15005953031的博客
04-11 358
####gdb常用指令 https://blog.youkuaiyun.com/niyaozuozuihao/article/details/91802994 ###生产core文件 g++ -g *.cpp 会生成一个a.out文件（有线程的话 末尾加 -lpthread） 生成core文件 1）改变core 文件大小 ulimit -c unlimited （ulimit -c 可以查看当前core文件大小，默认core是不生成的 ls-lh以字节形式查看） gdb a.out cor
代码查错方法之gdb生成core文件
weixin_50051374的博客
03-15 737
core文件的生成和路径设置 在程序崩溃时，内核会生成一个core文件,即程序最后崩溃时的内存映像，和程序调试信息。之后可以通过gdb,打开core文件察看程序崩溃时的堆栈信息，可以找出程序出错的代码所在文件和函数。 ①：core文件的生成开关和大小限制： 1）使用 ulimit -a 命令，可以察看core文件的生成开关和大小限制所有信息（输出内容中 core file size，若为0表示不生成core文件） 2）使用 ulimit -c 命令可查看core文件的生成开关。若结果为0，则表示关闭了
gdb调试core文件
wuyihao123的博客
05-02 876
如果程序在运行的过程中发生了内存泄漏，会被内核强行终止，提示“段错误（吐核）”，内存的状态将保存在core文件中，方便程序员进一步分析。Linux缺省不会生成core文件，需要修改系统参数。调试core文件的步骤如下：1）用ulimit -a查看当前用户的资源限制参数；2）用把改为unlimited；3）运行程序，产生core文件；4）运行gdb程序名core文件名；5）在gdb中，用bt查看函数调用栈。
简单复习gdb使用和core文件的生成方法和配置
谢白羽
01-06 5372
文章目录一、如何生成core文件1）设置core文件开关1）查看生成core文件的开关是否开启，输入命令# ulimit -a2）使用#ulimit -c [kbytes]可以设置系统允许生成的core文件大小；3) 永久生效修改coresize的方式4）指定生成文件的路径和名字；执行# vim /etc/sysctl.conf，进入编辑模式，加入下面两行5）测试是否能生成core文件：二、gdb预热1) gcc编译debug版本2) cmake设置编译debug版本三、开始gdb调试 一、如何生成core
使用GDB生成coredump文件
热门推荐
Sky_qing的专栏
01-28 1万+
如果在测试过程中遇到某个进程的CPU利用率过高或者卡死而需要去调试该进程时，可以利用gdb命令生成coredump文件，然后再去调试coredump文件来定位问题。 那么如何使用gdb生成coredump文件呢？其实步骤很简单： 1. 安装好gdb，然后使用命令 'gdb'。（假设需要调试的进程号为 21509） 2. 使用 ‘attach 21590’命令将gdb附加到进程2150
Linux下使用GDB生成core file文件并显示程序出错位置
道法自然
04-10 1130
Linux下使用GDB生成core file文件并显示程序出错位置
core文件调试（gdb）
weixin_40026739的博客
07-04 1万+
运行linux时，我们可以设定程序在崩溃的时候生成code文件。
有一个coredump文件，然后有去掉符号（stripped）的可执行文件，如何定位具体挂掉的位置
最新发布
11-08
<think>首先，用户的问题是关于如何利用coredump文件和去掉符号（stripped）的可执行文件来定位程序挂掉的具体位置。用户提到了coredump文件和stripped可执行文件，这意味着可执行文件已经被移除调试符号（symbols），这会使调试更困难，但不是不可能的。 用户提供了两个引用： - 引用[1]：讨论map被钉住（pinned），这似乎与eBPF或Linux内核相关，但与当前问题不太直接相关。 - 引用[2]：展示了一个C程序，讨论内存段如etext、edata、end，这些与程序的内存布局相关，可能有助于调试。 用户指定："上述引用仅供参考，并不是用户真正的需求，请尽可能多的参考用户上一次的问题和你的回答。" 但在这个对话中是第一次互动，所以没有上一次的问题或回答。因此，我应该专注于当前问题。 关键点：用户想定位程序挂掉的具体位置，使用coredump和stripped可执行文件。 核心思路： - **Coredump文件**：这是程序崩溃时生成的映像文件，包含程序状态（如寄存器值、内存内容、栈帧等）。 - **Stripped可执行文件**：移除了调试符号，如函数名、变量名，但保留了代码段和数据段。调试时需要额外信息或工具来映射地址到源代码位置。 方法： 1. **使用调试器（如GDB）**：即使可执行文件被stripped，GDB仍然可以加载coredump文件和可执行文件，并提供一些调试信息。 2. **获取符号表**：如果可能，获取未stripped版本的符号表或调试信息文件（如.dbg文件）。 3. **分析栈追踪**：从coredump中提取栈指针和指令指针，解析地址。 4. **使用工具**：如objdump、addr2line等，结合可执行文件和coredump。 5. **内存段分析**：引用[2]提到了etext、edata、end，这些是程序内存段的地址标识符，在调试时可以用来定位代码和数据段的位置。 步骤指南（基于GDB）： - 加载coredump和可执行文件进GDB。 - 检查崩溃点：查看指令指针（eip或rip），了解崩溃时执行的位置。 - 解析栈：使用bt命令获取栈回溯，但由于stripped，可能只显示地址。 - 使用地址映射：如果有源代码或符号表，可以映射地址到函数和行号。 - Alternative：如果没有符号表，使用objdump反汇编可执行文件，找到对应的地址范围。 具体步骤： 1. **准备文件**：确保有coredump文件（如core.*）和stripped可执行文件。 2. **启动GDB**：运行`gdb <path/to/executable> <path/to/coredump>`。 3. **获取崩溃点**：GDB通常会显示崩溃时的寄存器状态和指令指针。 4. **栈回溯**：使用`bt`或`backtrace`命令。由于stripped，可能显示为地址而不是函数名。 5. **反汇编**：使用`disassemble`命令或`objdump -d`来反汇编可执行文件，找到指令指针对应的汇编代码。 6. **映射到源代码**：如果可能，获取未stripped版本或使用调试符号文件。 7. **使用地址信息**：引用[2]中的示例展示了如何打印内存段地址，这可以帮助理解代码段和数据段的位置。例如，etext是代码段结束，edata是初始化数据段结束，end是BSS段结束。 8. **分析内存**：检查寄存器值和内存内容来推论崩溃原因。 其他工具： - `addr2line`：转换地址到源代码行号，但需要符号表。 - `nm`：列出符号，但stripped文件可能没有。 - `readelf`：查看ELF文件信息。 既然用户提到了引用[2]，我可以融入内存段的概念： - 在coredump中，可以使用地址如&etext等来定位关键段，帮助缩小搜索范围。 - 例如，崩溃点的地址如果落在.text段（代码段）中，可以反汇编该区域。 回答结构： 1. **介绍问题**：解释在stripped可执行文件下调试coredump的挑战。 2. **基本步骤**：给出使用GDB的详细步骤。 3. **利用内存段信息**：结合引用[2]，说明如何用etext、edata等辅助定位。 4. **高级方法**：讨论如果没有符号表的应对策略。 5. **相关工具**：提到其他有用的工具。 6. **生成相关问题**：根据系统指令，添加相关问题。 系统指令： - 行内数学使用$...$，但这个问题不需要数学。 - 独立公式使用$$...$$，但可能不需要。 - LaTeX语法正确：在回答中避免使用LaTeX，除非必要。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾添加引用标识：[^1]或[^2]，但用户提供的引用仅供参考，我应该基于内容引用。 相关问题： 1. 如何生成coredump文件？ 2. 如何保存未stripped的可执行文件用于调试？ 3. 在没有coredump的情况下如何调试程序崩溃？ 4. 如何使用etext、edata等地址在调试中？ 5. 在Linux中如何处理strip后的二进制调试？ 最终回答： - 结构化、清晰。 - 参考用户提供的引用，但不要强行插入无关内容。 </think>### 利用 coredump 文件和 stripped 可执行文件定位程序挂掉位置的方法 当程序崩溃时，coredump 文件保存了崩溃瞬间的内存状态（如寄存器值、堆栈内容），而 stripped 可执行文件移除了调试符号（如函数名、行号信息），这加大了调试难度。但通过以下方法，仍可定位具体崩溃位置。核心思路是结合地址映射、寄存器分析和工具解析。以下步骤基于 Linux 环境（使用 GDB 等工具），分为基础步骤和高级策略。 #### 基础步骤：使用 GDB 加载和分析 1. **加载文件和获取崩溃点** 在终端中运行 GDB，加载 stripped 可执行文件和 coredump 文件： ```bash gdb /path/to/stripped_executable /path/to/coredump ``` GDB 会自动显示崩溃时的关键寄存器值，尤其是指令指针寄存器（RIP 或 EIP），它指向崩溃时执行的代码地址。例如： ``` Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000555555555123 in ?? () ``` 这里的 `0x0000555555555123` 是崩溃点的虚拟地址。 2. **反汇编代码段定位附近指令** 由于符号被移除，需通过反汇编找到地址对应的汇编指令： - 在 GDB 中运行： ```gdb (gdb) disassemble 0x0000555555555123-20, +20 # 反汇编地址前后范围 ``` 输出会显示汇编代码，例如： ``` 0x0000555555555110: mov %rax,(%rbx) 0x0000555555555113: test %eax,%eax 0x0000555555555123: callq 0x555555555000 # 崩溃点 ``` 分析指令判断错误类型（如空指针访问、非法调用）。 3. **栈回溯分析调用链** 使用 `backtrace` 命令获取函数调用栈，但由于符号缺失，栈帧显示为地址： ```gdb (gdb) bt #0 0x0000555555555123 in ?? () #1 0x0000555555555180 in ?? () #2 0x00007ffff7a03c87 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 ``` 记录所有地址，用于后续映射。 4. **结合内存段地址缩小范围** 引用[2]中提到的 `etext`、`edata`、`end` 符号（即使 stripped，这些全局符号通常保留）可帮助定位内存段边界： - `&etext`：代码段（.text）结束地址，包含程序指令。 - `&edata`：初始化数据段（.data）结束地址。 - `&end`：未初始化数据段（.bss）结束地址。 在 GDB 中打印这些地址： ```gdb (gdb) print/x &etext $1 = 0x555555556000 (gdb) print/x &edata $2 = 0x555555557000 ``` 比较崩溃地址（如 `0x0000555555555123`）： - 若地址在 `&etext` 范围内（例如 `0x555555556000`），属于代码段，应反汇编分析。 - 若在 `&edata` 或 `&end` 附近，可能涉及数据访问错误（如缓冲区溢出）。 #### 高级策略：无符号表时的应对方法 - **使用 objdump 反汇编可执行文件** 导出整个代码段，搜索崩溃地址： ```bash objdump -d /path/to/stripped_executable > disassembly.txt grep -C 10 '0x0000555555555123' disassembly.txt # 搜索地址上下文 ``` 结合崩溃指令（如 `callq`）推断函数调用。 - **地址到源代码的间接映射** - 如果有未 stripped 版本或编译时的 .map 文件，用 `addr2line` 映射： ```bash addr2line -e /path/to/unstripped_executable 0x0000555555555123 ``` 输出如 `main.c:15`（行号）。 - 若无未 stripped 文件，基于反汇编和源码逻辑推测：例如，崩溃在循环或系统调用附近。 - **分析 coredump 内存内容** - 检查寄存器指向的内存： ```gdb (gdb) x/x $rbx # 查看寄存器 RBX 指向的值 ``` 若值非法（如 0x0），可能是空指针解引用。 - 引用[2]中的堆分配示例：崩溃若涉及 `malloc` 返回的指针（如 `p`），检查其是否被释放或越界。 - **自动化工具辅助** - `gdb-peda`（GDB 插件）：增强内存分析，自动检测漏洞模式。 - `coredumpctl`（Systemd 系统）：管理 coredump，简化加载。 #### 注意事项 - **原子性保证**：如引用[1]所述，map 更新是原子的，这意味 coredump 中的内存状态一致，减少干扰[^1]。 - **符号保留**：编译时用 `-g` 保留符号，调试后 strip，避免此问题。 - **崩溃原因常见类型**：段错误（SIGSEGV）多由内存访问错误引起，结合反汇编和寄存器值优先检查指针操作。 通过以上方法，即使可执行文件 stripped，也能定位到崩溃的具体指令位置。需耐心分析地址和内存布局。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值