前两天一个做工业上位机的朋友在群里甩了张截图程序在客户现场跑了六个小时突然没了终端上干干净净日志最后一行还是正常的采集数据。他问我Linux下Qt生成程序崩溃文件这事儿到底该怎么弄为什么我这边跑得好好的一到现场就人间蒸发这个问题我太熟了从早期的嵌入式ARM板子到现在的x86服务器我自己踩过的坑能装满一箩筐。所谓程序崩溃文件在 Linux 语境下通常指 core dump核心转储它是内核在进程收到致命信号时把整个进程地址空间快照写到磁盘的产物而 Qt 程序因为有自己的事件循环、元对象系统和线程模型光把系统层面的 core 打开还不够很多时候你还需要在应用层自己抓一份带符号的堆栈。这篇就围绕 Linux、Qt、程序崩溃文件这三个词把我这几年从崩溃后一片空白到五分钟定位到具体某一行的完整链路讲清楚适合正在用 Qt 做客户端、后台服务或者嵌入式界面的朋友也适合刚接手别人 Qt 项目、被线上崩溃搞得头大的同学。1. 为什么Qt程序崩溃后经常什么都没留下1.1 先分清三种崩溃文件不是一回事很多人一上来就问core文件在哪其实在 Linux 上一个 Qt 程序异常退出可能对应三种完全不同的产物混在一起聊必然乱。第一种是内核 core dump由内核在 SIGSEGV、SIGABRT、SIGBUS、SIGFPE、SIGILL 等致命信号触发时生成内容是完整的进程内存镜像加寄存器现场用 gdb 加载后能看到任意线程的完整调用栈和局部变量这是信息量最大的一种。第二种是应用自己写的 crash log比如在信号处理函数里调用 backtrace() 拿到地址数组再把符号解析出来写进自定义格式的文本文件优点是轻量、可控、方便上报缺点是受限于信号处理函数的异步安全性能做的事情很有限。第三种是 Qt 自己的日志输出比如 qDebug、qWarning、qFatal 以及 qInstallMessageHandler 接管后的消息它记录的是程序死之前在干什么属于上下文而不是现场。注意core dump 和 crash log 是互补关系不是替代关系。线上环境应该尽量两个都要一个负责精度一个负责可读性和上报效率。我一般把这三者看成刑侦里的三样东西core 是案发现场全景照片crash log 是证人证词Qt 日志是时间线。只有全景照片没有时间线你会知道人是怎么倒下的但不知道他为什么走到那儿只有时间线没有全景照片你能猜到动机但拿不到决定性证据。1.2 Qt 的元对象机制为什么让崩溃现场更脏纯 C 程序的崩溃栈通常很直白一层调用一层gdb 一 bt 就出来了。Qt 程序不一样信号槽机制会在调用栈里插入一层 QMetaObject::activate事件循环会把真正的业务逻辑藏在一堆 QCoreApplication::notify、QApplication::notify、QEventLoop::exec 底下。堆栈里最常见的形态是主线程卡在 QEventLoop::exec 里上面挂着 QMetaObject::activate再往上是某个槽函数崩在槽函数内部。如果你只看表层很容易误判成事件循环崩了实际上事件循环无辜得很。更麻烦的是 QObject 的父子关系和 deleteLater 机制。一个对象被 deleteLater 投递了删除事件但事件还没处理此时另一处代码仍然持有裸指针并调用了它的成员函数你会崩在一个看起来完全无关的虚函数调用上backtrace 里显示的是 QObject::~QObject 或者某个 vtable 相关的位置毫无头绪。这种崩溃如果不开 core基本靠猜。开了 core用 gdb 打印p *this和对象地址往往就能看出这个对象的上层已经被析构了。1.3 方案选型我为什么推荐系统core 应用层handler双轨市面上关于崩溃捕获的方案大致三种路线。路线一是纯内核 core配置简单只在系统层面动刀不动一行业务代码缺点是文件体积大Qt 程序动辄几百 MB 到几个 GB、可能包含敏感内存数据、在容器和嵌入式环境里经常被默认禁用。路线二是纯应用层 handler比如集成 Google Breakpad 或者自己写 backtrace优点是跨平台、文件小、能自定义上报缺点是在栈被破坏的场景下 backtrace 可能拿不到有效信息而且信号处理函数里能做的事实上很少。路线三是外部监控比如用 systemd-coredump、abrt 或者自建守护进程监听子进程退出状态适合服务端守护场景。我的实际选择是开发测试机走路线一把 core 完整打开方便追根溯源正式发布的客户端走路线二为主、路线一为辅崩溃时先写一份精简的、带符号信息的自定义 crash log 上报同时在用户机器上按需保留 core可以通过配置开关控制。这个组合在工业现场那种不能联网、不能远程调试、只能靠U盘拷日志的环境里救过我很多次。2. 内核层配置让 core dump 真正落到磁盘上2.1 三个必须先捋顺的开关Linux 上 core dump 能不能生成、生成到哪、叫什么名字由三个地方共同决定任何一个不对都会导致配置了但没有文件。第一个是进程的资源限制 RLIMIT_CORE。用ulimit -c查看如果返回 0说明当前 shell 启动的所有进程都不允许写 core。临时打开用ulimit -c unlimited但注意这只对当前 shell 会话及其子进程生效重启就没了。要永久生效桌面环境改/etc/security/limits.conf服务端如果走 systemd则要在 unit 文件里写LimitCOREinfinity因为 systemd 管理的进程不读 limits.conf 的交互式配置这是新手最常翻车的地方。第二个是/proc/sys/kernel/core_pattern它决定 core 文件的落盘路径和命名规则。默认值常见的是core意思是写在进程当前工作目录下文件名就叫 core。这在 Qt GUI 程序里非常坑因为工作目录可能是用户主目录、可能是桌面、也可能是某个只读目录你根本不知道去哪儿找。第三个是/proc/sys/kernel/core_uses_pid值为 1 时会在文件名后面追加进程号多进程同时崩溃时不会互相覆盖建议打开。# 查看当前状态 ulimit -c cat /proc/sys/kernel/core_pattern cat /proc/sys/kernel/core_uses_pid # 临时生效当前会话 ulimit -c unlimited echo 1 | sudo tee /proc/sys/kernel/core_uses_pid echo /var/crash/core-%e-%p-%t | sudo tee /proc/sys/kernel/core_pattern上面这个 pattern 里%e是可执行文件名%p是进程号%t是崩溃发生的 Unix 时间戳这三者组合起来基本能保证唯一性。落盘目录/var/crash需要提前创建并保证运行用户有写权限我一般会写成 1777 或者归属到专门的分析账号下权限过松会有安全顾虑过紧又写不进去这个要按现场环境权衡。2.2 管道模式core_pattern 里那个竖线千万别忽略如果你在 core_pattern 开头看到|说明系统启用了管道模式内核不会直接写文件而是把 core 内容通过标准输入交给后面那个程序处理。现在主流发行版默认就是这一套比如|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h。这种情况下你在当前目录下当然找不到 core 文件因为它被 systemd 收走了。用coredumpctl list能看到历史崩溃记录coredumpctl info PID看详情coredumpctl gdb PID直接带 core 进 gdb。这套机制的好处是自动压缩、自动清理、自动记录元信息我个人在桌面发行版上非常喜欢用。坏处是它对嵌入式裁剪系统和某些定制内核不友好而且分析时多绕一层很多老工程师不习惯。如果你想让 core 老老实实写文件就得把 core_pattern 改掉去掉前面的管道。但要注意改成纯文件模式后systemd-coredump 就不再介入了之前的历史记录也查不到了。改之前建议先确认现场是否需要保留 coredumpctl 这套流程。# 改回文件模式 echo /var/crash/core-%e-%p-%t | sudo tee /proc/sys/kernel/core_pattern # 或者继续用 systemd 的管道但调整存储位置和大小 sudo mkdir -p /etc/systemd/coredump.conf.d sudo tee /etc/systemd/coredump.conf.d/custom.conf EOF [Coredump] Storageexternal Compressyes ProcessSizeMax8G ExternalSizeMax8G MaxUse20G EOF sudo systemctl daemon-reload这里有个经验值可以参考一个带 QtWebEngine 或者 QtQuick 的进程core 文件大小大概是常驻内存的 1 到 1.5 倍。如果程序常驻 500MB你要预留至少 800MB 空间。我之前在一个只有 2GB 剩余空间的工控机上排查core 写到一半磁盘满了文件被截断gdb 加载直接报 is not a core dump: file format not recognized白白浪费一晚上。所以ProcessSizeMax和实际磁盘余量一定要对齐。2.3 用一个必崩的 Qt 小程序做验证配置完不要急着上真实项目先写个最小例子确认链路是通的。这是我自己的习惯验证五分钟省得后面排查半小时。// main.cpp #include QCoreApplication #include QTimer #include QDebug int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); qDebug() pid QCoreApplication::applicationPid(); QTimer::singleShot(1000, []() { int *p nullptr; *p 42; // 故意制造 SIGSEGV }); return app.exec(); }用qmake或者 CMake 构建编译时必须带上-g否则你拿到 core 也看不到行号。跑起来之后用echo $?看退出码SIGSEGV 对应 13912811SIGABRT 对应 1341286。看到这两个数字基本可以确定是信号导致的异常终止而不是正常 exit。g -g -O0 -fno-omit-frame-pointer main.cpp -o crashdemo \ $(pkg-config --cflags --libs Qt5Core) ulimit -c unlimited ./crashdemo echo $? ls -lh /var/crash/验证通过之后再往项目上套心里就有底了。这一步千万别省我见过太多人上来就改生产环境配置结果一路怀疑人生。2.4 容器、AppArmor 与只读文件系统的干扰如果你在 Docker 或者类似的隔离环境里跑情况会复杂一些。容器默认的 core_pattern 通常继承宿主机但 core 文件会写到容器内部的路径容器一销毁文件就没了所以要么挂载卷要么用--ulimit coreinfinity配合把 core 目录映射出来。另外很多安全加固策略会限制 ptrace 和 core dump比如某些发行版的 AppArmor 配置文件里有deny /var/crash/** w之类的规则日志里能看到 audit 记录。排查这类问题的办法是看dmesg和journalctl -k内核在拒绝写 core 的时候通常会留一条线索。还有一类是只读根文件系统嵌入式板子上非常普遍。这时候 core_pattern 指向的目录必须是可写分区一般会选/tmp、/data或者挂载的 SD 卡。但/tmp往往是 tmpfs掉电即失如果你需要事后取证一定要落到持久化分区。我自己在 ARM 板子上习惯建一个/data/crash目录把 core_pattern 指过去同时写个开机脚本定期清理超过 7 天的文件防止把 eMMC 写满。3. Qt 应用层自己抓一份看得懂的崩溃堆栈3.1 该捕获哪些信号不该碰哪些应用层 handler 的核心是sigaction注册信号处理函数。我通常捕获这几个SIGSEGV非法内存访问Qt 里最常见的崩法、SIGABRTabort 调用Qt 的 qFatal 和标准库 assert 都会走到这里、SIGBUS总线错误ARM 上对齐问题常见、SIGFPE除零、SIGILL非法指令通常意味着二进制和 CPU 指令集不匹配或者栈被踩烂了。有几点必须明确。SIGKILL 和 SIGSTOP 是无法捕获的这是内核层面的硬性规定别浪费时间。SIGTERM 和 SIGINT 我一般也捕获但那属于正常退出路径捕获后走优雅关闭流程就行不要当成崩溃处理否则你的事务日志里会混进一堆正常的关闭记录。注意注册信号处理函数时一定要用sigaction而不是老式的signal并且要带SA_SIGINFO标志这样才能在 handler 里拿到siginfo_t从中读出出错地址和信号来源。另外要用SA_RESETHAND或者手动重置避免同一信号反复触发导致 handler 无限递归。3.2 信号处理函数里能做和绝对不能做的事这是整个方案里技术含量最高、也最容易写错的地方。信号处理函数的执行上下文是异步的它可能在任意一条指令之后被触发这意味着你只能调用异步信号安全的函数。什么叫异步信号安全简单说就是那些可重入、不依赖全局状态、不分配内存、不产生内部锁的函数比如write、open、close、_exit、sigaction、memcpy严格说 POSIX 对 memcpy 是否安全有争议实践中广泛使用。绝对不能在里面做的事情包括调用 malloc/free、调用 printf 格式化输出、调用任何 Qt 的函数QString、QFile、qDebug 全部不行、调用 C 的异常抛出、加锁。我见过有人在信号处理函数里直接QFile file(crash.log); file.write(...)程序在崩溃时又崩了一次最后什么都没写出来还多了一个更难排查的问题。那怎么在 handler 里拿到堆栈答案是backtrace()和backtrace_symbols()这对组合本身也不保证异步信号安全它们内部可能分配内存但它们在实践中几乎从不失败工业界大量项目在用。稳妥的做法是在 handler 里只调用backtrace()把地址数组拷到一块预分配的静态缓冲区然后用write()直接把原始地址写进一个已经open好的文件描述符剩下的符号解析、格式化、上报全部放到崩溃后重启的进程里做或者干脆离线用脚本处理。#include execinfo.h #include fcntl.h #include signal.h #include unistd.h #include cstring namespace { constexpr int kMaxFrames 64; void *g_frames[kMaxFrames]; int g_fd -1; void crashHandler(int sig, siginfo_t *info, void *ucontext) { (void)ucontext; // 只做异步信号安全的事 int n backtrace(g_frames, kMaxFrames); if (g_fd 0) { const char *name SIG?; switch (sig) { case SIGSEGV: name SIGSEGV; break; case SIGABRT: name SIGABRT; break; case SIGBUS: name SIGBUS; break; case SIGFPE: name SIGFPE; break; case SIGILL: name SIGILL; break; } write(g_fd, name, strlen(name)); write(g_fd, \n, 1); if (info) { // 出错地址字面量避免格式化 const char *prefix fault_addr0x; write(g_fd, prefix, strlen(prefix)); } backtrace_symbols_fd(g_frames, n, g_fd); } // 重置默认处理重新抛出信号让内核也生成 core signal(sig, SIG_DFL); raise(sig); } } // namespace这段代码的关键点在最后几行处理完自己的逻辑后把信号恢复成默认行为再raise一次这样内核仍会按 core_pattern 生成标准 core 文件两套机制完美衔接。很多人漏了这一步结果自己的 log 写了系统的 core 却没了。3.3 backtrace 与 libunwind、Breakpad 的取舍backtrace系列来自 glibc好处是零依赖、代码量极小坏处是它依赖帧指针frame pointer。如果编译时开了-O2 -fomit-frame-pointer很多发行版默认就这么干栈回溯会断层中间少几层甚至只回溯出一两层。所以我的做法是即使发布版本也要保留-fno-omit-frame-pointer同时用-g1保留最基本的信息这样对性能影响很小但崩溃时的可读性提升巨大。libunwind 不依赖帧指针靠 DWARF 展开表回溯更准确但引入了一个第三方依赖。在嵌入式环境里编译 libunwind 有时候也不轻松所以我一般只在 x86_64 的服务端用它。Google Breakpad 是另一条路线它跨平台做得最好能生成 minidump 文件体积小几百 KB配合符号服务器可以在服务端还原完整堆栈非常适合有大量客户端的桌面软件。缺点是引入成本高符号管理需要额外搭建而且 minidump 不能直接给 gdb 用需要转成 core 或者用专门的工具。如果你做的是给几千台机器铺出去的客户端Breakpad 值得投入如果只是内部工具backtrace 加 core 完全够用。方案依赖文件体积语义完整度适用场景glibc backtrace无KB 级中依赖帧指针内部工具、嵌入式libunwind需编译KB 级高x86 服务端Google Breakpad较重几百 KB高需符号服务大规模客户端内核 core dump无百 MB 级最高含变量开发与现场取证3.4 把 Qt 的日志上下文一起带上光有堆栈还不够你还需要知道崩之前程序在干什么。Qt 提供了qInstallMessageHandler可以接管 qDebug、qWarning、qCritical、qFatal 的输出。我一般会做一个环形缓冲区保留最近 N 条比如 500 条带时间戳、线程 ID、日志级别的消息崩溃时把这块缓冲区一次性 dump 到文件里。#include QCoreApplication #include QDateTime #include QFile #include QMutex #include QTextStream #include deque namespace { struct LogItem { QString time; quintptr threadId; QString text; }; QMutex g_mutex; std::dequeLogItem g_buffer; constexpr size_t kBufferSize 500; void messageHandler(QtMsgType type, const QMessageLogContext ctx, const QString msg) { QMutexLocker locker(g_mutex); LogItem item; item.time QDateTime::currentDateTime() .toString(yyyy-MM-dd HH:mm:ss.zzz); item.threadId reinterpret_castquintptr(QThread::currentThreadId()); item.text msg; g_buffer.push_back(item); if (g_buffer.size() kBufferSize) g_buffer.pop_front(); QTextStream(stderr) item.time [ item.threadId ] msg \n; } } // namespace然后在信号处理函数里注意这里 qt 函数不能用了要走预先把内容序列化好的路径或者更稳妥地在启动的看护进程里把 g_buffer 的内容写到崩溃日志旁边。实践中我更推荐看护进程方案主程序崩溃父进程检测到子进程异常退出然后从共享内存或者刚才 dump 出来的环形缓冲区文件里读取上下文。这样完全规避了信号安全的限制代价是要多写一点进程间通信的代码。顺便提一句 Qt 版本差异。5.14 和 5.15.2 这两个 LTS 在这块行为基本一致qInstallMessageHandler 的签名没变。但如果你用的是更早的版本某些 Qt 模块比如串口在配置阶段就容易出问题绕开那些安装期的坑之后再谈崩溃捕获会顺很多不然你连程序都跑不起来。3.5 编译与符号让堆栈从问号变成行号这是另一个高频痛点。你拿到了 backtrace 的输出一堆./myapp(0x4a1f)[0x55...]完全看不懂。原因通常是二进制的符号表被 strip 掉了或者编译时没加-g。正确做法分两种情况。开发阶段直接-g -O0 -fno-omit-frame-pointer堆栈信息最全。发布阶段我推荐保留符号但不发布的策略构建时生成一份带完整调试信息的二进制myapp.debug再用objcopy --only-keep-debug把调试段单独抽出来主程序 strip 掉调试信息但保留动态符号表最后用objcopy --add-gnu-debuglink把两者关联起来。# 构建时保留调试信息 g -g -O2 -fno-omit-frame-pointer main.cpp -o myapp # 抽出调试段 objcopy --only-keep-debug myapp myapp.debug # 主程序剥离调试信息但保留必要符号 strip --strip-debug --strip-unneeded myapp objcopy --add-gnu-debuglinkmyapp.debug myapp # 事后分析时把 myapp 和 myapp.debug 放同一目录gdb 自动加载 gdb ./myapp core.12345如果没有 .debug 文件也可以用addr2line手动把地址翻译成源码位置前提是地址要减去加载基址对 PIE 可执行文件。这一步的偏移量计算是很多人卡住的地方我的经验是在 gdb 里直接用info line *0x地址更省事它会自动处理重定位。或者更简单粗暴一点用set disable-randomization on关闭 ASLR 再跑地址就是固定的省去换算烦恼但只适合开发环境。4. 崩溃文件拿到手之后的完整分析流程4.1 gdb 加载 core 的标准动作清单拿到 core 之后我一般按固定顺序做这几件事基本能在十分钟内锁定方向。先把可执行文件和 core 放同一个目录执行gdb ./myapp core.12345。进来第一件事是bt看主线程栈如果主线程是好的就info threads列出所有线程然后thread apply all bt一次性把全部线程栈打出来。Qt 程序多线程是常态崩溃的那个线程往往不是主线程只盯主线程会白忙活。接着用frame N切到可疑帧info locals看局部变量info args看参数p *this看对象状态。如果发现某个指针看起来像垃圾值比如 0x5a5a5a5a 或者很小的地址那基本就是野指针或者已经释放的对象。这时候可以进一步用p this-children()之类的调用但要小心某些调用本身可能不安全读内存比执行代码稳妥。gdb ./myapp core.12345 (gdb) set pagination off (gdb) bt (gdb) info threads (gdb) thread apply all bt full (gdb) info sharedlibrary (gdb) frame 5 (gdb) info locals (gdb) p *this (gdb) x/16gx $rspinfo sharedlibrary这一步在 Qt 程序里特别重要因为崩溃点经常落在 libQt5Core.so 或者某个插件 so 里你需要确认实际加载的库版本和你本地用来分析的版本一致。版本不一致会导致堆栈错位分析出来的结果全是错的这是堆栈看起来毫无逻辑的常见原因之一。4.2 Qt 项目里最常撞上的几类崩溃模式做了这么多年 Qt崩溃原因翻来覆去就那么几类我把命中率最高的整理一下。第一类是跨线程操作 GUI 对象比如在子线程里创建 QWidget、调用 QPixmap 的加载接口、或者直接调用某个 QWidget 的 update。Qt 明确规定 GUI 相关类只能在主线程使用违反这条规则时程序不一定立刻崩可能跑几百次才崩一次堆栈显示在 QPixmap 内部或者 QPaintDevice 相关位置。这类问题的排查技巧是看崩溃线程号如果不是主线程却在动绘图对象基本就实锤了。第二类是信号槽连接悬垂指针。对象已经被 delete 了但连接还在下一次信号触发时直接访问已释放内存。老版本 Qt 的 connect 写法不检查生命周期新版本用函数指针语法配合 context 对象能自动断开所以我的建议是能用新语法就用新语法。如果你在 core 里看到 QMetaObject::activate 下面紧跟一个奇怪的虚函数调用八成就是这个。第三类是静态对象析构顺序。Qt 程序退出时 QApplication 先析构之后如果还有静态的 QObject 派生对象在析构函数里访问 Qt 的全局状态比如 QCoreApplication::instance()就会崩在退出阶段而不是运行阶段。这类崩溃的特点是只在正常退出时出现日志看起来一切正常最后突然掉出来一个 core。第四类是绘图相关。除了跨线程 QPixmap还有在 paintEvent 之外使用 QPainter、QPainter 对象未正确 end、QImage 和 QPixmap 混用导致的数据竞争。如果你在堆栈里看到 QPainter 相关的符号出现在非主线程优先怀疑这个方向。绘图效率和多线程绘图是很多人喜欢折腾的地方但线程拆分一定要把绘图对象严格隔离在各自的线程里否则崩溃几乎是必然的。4.3 发布版怎么留一条能追溯的线发布版的难点在于你不能把带完整符号的二进制发出去体积大、有安全顾虑但又必须在客户现场能拿到可用的信息。我的做法是维护一个版本到符号包的映射表每次构建生成一个version-buildid标识把符号包存在内部服务器上。客户端崩溃时自定义 handler 生成的日志里带上这个构建 ID运维把日志发回来我在服务器上按 ID 找到对应的符号包用eu-stack或者 gdb 离线还原堆栈。如果不想搞这么重还有个轻量做法在发布版里集成一个简易的符号化工具程序收到崩溃信号后不用 gdb而是用dladdr加abi::__cxa_demangle把邻近的符号名解析出来虽然拿不到行号但能看到函数名定位效率已经能提升好几倍。这个方案我在几个只有几百行代码的工具类项目里用过性价比很高。4.4 自动化上报的几点设计考虑如果你的软件铺得比较广一定要做自动上报不然靠用户手动发日志迟早会崩。设计上有几个点要注意。首先是限流同一个构建版本的同一种崩溃每天最多上报几条否则一个线上问题可能瞬间把你的接收端冲垮。其次是脱敏core 文件里可能包含用户数据、路径、内存里的字符串上报前要么只上报符号化后的堆栈文本要么过滤掉敏感字段。第三是网络失败要静默降级不能因为上报把主程序退出流程卡住我一般在单独线程里做且设置两三秒的超时。还有一点容易忽略崩溃上报本身可能失败比如崩溃发生在网络模块内这时候你要保证 handler 不会递归调用。我的做法是在 handler 开头用一个volatile sig_atomic_t标志位做守卫进来先置位如果发现已经是 1 就直接走默认路径什么都不做。这个小技巧避免过好几次崩溃处理器自己崩溃的死循环。5. 高频问题速查与踩坑经验5.1 core 文件不生成的原因清单这个问题被问得最多我整理成一张表按从高到低的可能性排列方便你逐条排查。现象可能原因排查命令解决方式完全没有文件ulimit -c 为 0ulimit -c改为 unlimitedsystemd 下加 LimitCORE当前目录没有core_pattern 走了管道cat /proc/sys/kernel/core_pattern用 coredumpctl 查或改 pattern文件大小是 0磁盘满或权限不足df -h、ls -l目录换目录、调整权限文件被截断大小超限或写入中断file core调大 ProcessSizeMax清理空间容器里找不到未挂载卷、容器已销毁docker inspect挂载外部卷、限制退出时间偶发没有崩溃在 handler 内部递归看自定义日志加守卫标志位、SA_RESETHAND只在某台机器没有安全策略拦截journalctl -k、dmesg调整安全策略或换路径这张表我自己用了好几年基本上遇到新问题往里一对照就能定位方向比盲目搜索快得多。5.2 堆栈里全是问号的三种解法第一种二进制被 strip 了。解决办法是保留独立的 debug 文件或者至少不要 strip 掉动态符号表。用file myapp看是不是 stripped用nm -D myapp | head看动态符号还在不在。第二种编译时没开-fno-omit-frame-pointer或者开了很高的优化等级导致内联严重。这种情况可以试试-O1配合-fno-omit-frame-pointer或者在 gdb 里试试bt不行就换info frame手工推。如果项目允许引入 libunwind 用 DWARF 展开是终极方案。第三种加载的库版本和分析环境不一致。这个最隐蔽堆栈看起来能打印但符号完全错位。解决方式是把现场环境的 Qt 库版本问清楚用相同版本的库来加载 core。我通常会在程序启动时把qVersion()和关键库的路径、md5 写进日志这样事后对不上号时一眼就能发现。5.3 守护进程、嵌入式与多进程场景的特殊处理守护进程通常会被 double fork 脱离终端工作目录也会被 chdir 到根目录这会导致 core 落到一个你意想不到的地方。我的习惯是在 daemon 初始化阶段显式chdir到一个固定目录同时把 core_pattern 配置成绝对路径双保险。嵌入式环境除了只读文件系统还要注意存储寿命。core 文件动辄几百 MB反复写会很快消耗掉 eMMC 的擦写次数。我的做法是在板上只保留最近一次崩溃的 core并且用一个单独的小分区写满就循环覆盖。同时把自定义 crash log体积只有几十 KB长期保留因为它才是日常排查的主力。多进程场景下如果主程序和子进程都会崩建议每个进程用不同的%e前缀区分。另外如果父进程会 fork 出大量短命子进程core_pattern 里的%p可能导致文件名爆炸这时候可以结合上报系统做去重只保留每个版本每种信号类型的第一份 core。5.4 我个人最想强调的几个习惯第一别等出事了才配。项目一开始搭好构建流程的时候就把-g -fno-omit-frame-pointer和崩溃 handler 加进去成本几乎为零收益是决定性的。我见过太多项目上线半年才想起来加结果前面积累的崩溃全都查不了。第二本地复现优先于远程分析。拿到 core 之后先想能不能在本地用同样的构建版本复现能复现就有一百种办法定位不能复现才需要啃 core。这个顺序反了会很痛苦。第三把版本信息、构建 ID、Qt 版本、系统架构这几项固定在崩溃日志头部。这几行字在跨团队协作时价值极高能省掉大量你用的是哪个版本的来回沟通。我自己写过一个很小的头信息 dump 函数每次崩溃日志都带后来成了团队标准。第四定期做崩溃演练。手动造几个必崩场景走完整链路确认从崩溃到定位到修复闭环是通的。这个习惯听起来多余但在关键时刻能救命。我曾在一个项目交付前一天做演练发现现场机器的 core_pattern 被安全加固改过如果没有这一步交付后的第一个线上问题就会变成无头悬案。最后再补充一个小技巧。如果你用的是 CMake可以在顶层CMakeLists.txt里对 Release 配置统一加上调试选项避免有人漏配。同时用CMAKE_BUILD_TYPE之外再定义一个自定义配置比如RelWithDebInfo其实就挺适合发布用的它自带-g和优化很多团队直接用它当发布配置。这些看起来不起眼的默认值往往决定了你半年后能不能顺利解开一个线上谜案。