Linux C++代码崩溃自动记录与溯源工具：快速定位段错误等部署难题

linux C代码崩溃查询工具及操作说明 真正的C部署工程往往比较多个模块协同运行代码量及代码复杂度都比较大 尤其在产品部署交付后车载边缘端服务器上出现各种问题此时溯源比较困难 尤其是出现段错误Segmentation fault (core dumped)时会感觉束手无策不知如何定位 您可以用我们提供的linux C代码崩溃查询工具该工具为指令脚本非C工程执行安装脚本后 只要当前系统中的任何C 工程出现崩溃都会进行记录方便您后面进行溯源 本商品提供脚本及说明文档非常简单不需要提供也不依赖第三方库谁懂啊车载边缘端跑着多模块耦合的C工程刚交付就突然炸段错误——远程登上去只能看到干巴巴的Segmentation fault (core dumped)连哪行代码崩的都摸不着。模块多、环境偏本地复现不了那真是挠破头的崩溃。直到用上这个纯脚本实现的崩溃监控工具终于不用再当“无头苍蝇”了。全程不依赖第三方库装完躺平系统里任何C程序崩了自动给你把溯源信息记下来省心到爆。先看怎么装一键搞定core dump配置首先得解决核心问题默认Linux环境大多关了core dump限制或者生成的core文件没标识、找不着。这个安装脚本直接帮你把这些配置拉满还把监控服务搭好。linux C代码崩溃查询工具及操作说明 真正的C部署工程往往比较多个模块协同运行代码量及代码复杂度都比较大 尤其在产品部署交付后车载边缘端服务器上出现各种问题此时溯源比较困难 尤其是出现段错误Segmentation fault (core dumped)时会感觉束手无策不知如何定位 您可以用我们提供的linux C代码崩溃查询工具该工具为指令脚本非C工程执行安装脚本后 只要当前系统中的任何C 工程出现崩溃都会进行记录方便您后面进行溯源 本商品提供脚本及说明文档非常简单不需要提供也不依赖第三方库给个安装脚本核心代码段#!/bin/bash # 1. 配置core dump生成规则 CORE_SAVE_DIR/var/crash/core_files LOG_SAVE_DIR/var/crash/crash_records mkdir -p $CORE_SAVE_DIR $LOG_SAVE_DIR # 放开core文件大小限制默认是0生成不了core echo * soft core unlimited /etc/security/limits.conf echo * hard core unlimited /etc/security/limits.conf # 配置core文件命名程序名-PID-时间戳避免覆盖 sysctl -w kernel.core_pattern${CORE_SAVE_DIR}/core_%e_%p_%t echo kernel.core_pattern ${CORE_SAVE_DIR}/core_%e_%p_%t /etc/sysctl.conf sysctl -p # 2. 写监控脚本自动抓崩溃栈 cat /usr/local/bin/crash_watcher.sh EOF #!/bin/bash CORE_DIR/var/crash/core_files LOG_DIR/var/crash/crash_records while true; do # 找3分钟内的新core文件避免重复处理 find $CORE_DIR -name core_* -mmin -3 | while read core_file; do log_name$(basename $core_file | sed s/core_/crash_log_/).txt log_path${LOG_DIR}/${log_name} if [ ! -f $log_path ]; then echo [$(date %Y-%m-%d %H:%M:%S)] 捕获程序崩溃$(basename $core_file) ${LOG_DIR}/watcher.log # 用gdb扒栈输出完整回溯寄存器信息 gdb -ex set pagination off -ex bt full -ex info registers -ex quit --core$core_file $log_path 21 # 尝试匹配程序可执行文件补全更详细信息 prog_name$(echo $core_file | grep -oP core_\K.*?(?_\d_)) if [ -n $prog_name ] which $prog_name /dev/null; then gdb -ex set pagination off -ex bt full -ex quit $(which $prog_name) $core_file ${log_path}.full 21 fi fi done sleep 20 # 每20秒扫一次目录 done EOF chmod x /usr/local/bin/crash_watcher.sh # 3. 做成systemd服务开机自启 cat /etc/systemd/system/crash-watcher.service EOF [Unit] DescriptionCrash Monitor Service Aftermulti-user.target [Service] Typesimple ExecStart/usr/local/bin/crash_watcher.sh Restartalways Userroot [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now crash-watcher.service echo 安装完成崩溃日志存于/var/crash/crash_records代码拆解这几步为啥重要core dump开关拉满/etc/security/limits.conf里改unlimited是因为默认用户进程的core文件大小被限制为0根本生成不了core文件——这是很多人碰过的坑程序崩了找不到core以为没开其实是大小限制没放。core文件命名规则kernel.core_pattern里的%e程序名、%pPID、%t时间戳是关键不然所有core文件都叫core新的会覆盖旧的查历史崩溃全白搭。监控脚本的懒处理不用复杂的inotify虽然更实时但依赖inotify-tools直接用find扫目录加时间过滤适合车载这种极简环境。每20秒扫一次足够也不占资源。gdb自动扒栈bt full比单纯bt多了局部变量的值对定位空指针、越界这种问题太有用了如果能找到程序的可执行文件带-g调试信息的话第二次gdb分析还能直接出代码行号。崩溃后怎么溯源看日志就行比如车载的carsensormodule崩了日志里会生成crashlogcarsensormodule12341698765432.txt打开直接看栈回溯#0 0x00007f9d12345678 in SensorParser::parseCanData(CanFrame*) () from /usr/lib/libcar_sensor.so #1 0x0000560a98765432 in SensorUpdateThread::run() () at src/sensor_thread.cpp:89 #2 0x00007f9d11abcdef in std::thread::_Implstd::_Bind_simpleSensorUpdateThread::*()(SensorUpdateThread*) ::_M_run() () from /usr/lib/libstdc.so.6 ...如果编译时加了-g参数一定要加不然只有内存地址还能看到src/sensor_thread.cpp:89——直接定位到线程里调用SensorParser::parseCanData的时候崩了大概率是CanFrame指针为空或者解析时数组越界。要是日志里还有.full后缀的文件里面的信息更全连程序加载的动态库版本、寄存器状态都有够你把问题拆得明明白白。最后提俩注意事项车载编译必加-g别为了减小包体积把调试信息扒干净不然gdb只能给你输出内存地址找不到具体函数和行号溯源效率直接砍半。权限问题必须用root装因为要改系统配置和systemd服务车载边缘端一般都是root权限跑程序不用怕权限不够生成不了core。说白了这个工具就是把“开core dump监控core文件自动gdb分析”这一套流程自动化了纯脚本实现没有花里胡哨的依赖车载边缘端这种资源有限、环境封闭的场景越简单的工具越好用。以后再遇到段错误直接去日志目录扒记录就行再也不用远程瞎折腾了。