### 启用
和生成CoreDump文件的方法
在开发过程中，当遇到程序崩溃的情况时，启用
Core Dump 文件能够帮助开发者
分析问题的根本原因。以下是在
ROS2 环境下配置
和生成 CoreDump 的方法。
#### 配置操作系统支持
CoreDump
Linux 默认情况下可能会禁用
CoreDump 或者对其大小进行了限制。因此，第一步是确保系统的
CoreDump 设置允许
生成完整的
dump 文件。
```bash
ulimit -c unlimited
```
这条命令会移除对
core 文件大小的任何限制，从而使得系统可以在进程崩溃时保存整个内存映像到磁盘上[^3]。
另外还需要确认 `/etc/security/limits.conf` 文件中有如下行未被注释掉：
```plaintext
* soft
core unlimited
* hard
core unlimited
```
同时也要检查是否有适当的目录供存储这些大尺寸的核心转储文档，默认路径通常位于工作区根目录或是由 `kernel.
core_pattern` 定义的位置。
#### 调整 Kernel 参数
有时即使设置了 ulimit ，仍然无法正常产生
coredump 。这时就需要修改内核参数进一步放开权限控制。
运行以下指令查看当前模式设定情况：
```bash
cat /proc/sys/kernel/
core_uses_pid
sysctl kernel.
core_pattern
```
理想状态下应返回值为 “1”，以及一个合理的 pattern 字符串比如 `"
cores/%e-%p-%t"` 表明每个
core file 将依据 executable name ( `%e`) , process ID (`%p`)
和 timestamp(`%t`) 命名存放在
cores 子文件夹里面[^4]。
如果发现不符合预期则可通过临时改变的方式立即生效而不需重启机器：
```bash
echo "/tmp/
core.%e.%p" | sudo tee /proc/sys/kernel/
core_pattern
sudo sysctl -w kernel.
core_uses_pid=1
```
#### 编译选项调整
为了让最终产物具备足够的调试信息以便后续解析 crash 场景，建议采用 Debug 构建而非 Release 版本。如果是 CMake 项目的话，记得把构建类型设回 debug 并重新编译所有关联模块。
```cmake
set(CMAKE_BUILD_TYPE "Debug")
add_compile_options(-g)
```
这样做的目的是让 GCC/G++ 添加额外的 symbol table entry 到 ELF binary 当中，方便
gdb 工具后期加载并解读异常现场数据结构关系图谱[^5]。
#### 测试验证
完成上述准备工作之后就可以尝试触发错误条件看能否成功留下对应的
core dump 记录了。假设有一个故意制造 segmentation fault 的简单 cpp demo :
```cpp
#include <cstdlib>
int main(){
*(volatile int *)NULL = 0; // Force SIGSEGV signal.
return EXIT_SUCCESS;
}
```
编译它成为可执行目标文件后直接执行即可观察效果。如果没有特别指定 handler 处理机制的话，那么按照前面所做的各项安排应当顺利产出相应的
core.<pid> 形式的二进制快照资料待查证。
---
### 总结
综上所述，在
ROS2 中启用
CoreDump 主要涉及三个方面的操作：一是合理调节 shell session 下面关于 resource limit 的策略；二是适当修正 linux 内核层面影响
core generation behavior 的几个关键属性；三是确保源码级别保留充分详尽的信息辅助事后剖析事故真相。只有三管齐下方能达到最佳诊断目的。
本文介绍如何使用Valgrind或GDB调试ROS节点，并提供生成coredump文件的方法，以便于更深入地进行问题定位和解决。
扫一扫
214
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
