1. Glog异常捕获机制的设计背景在C服务端开发中程序崩溃时的信息捕获一直是个痛点。传统的core dump文件虽然能保留堆栈信息但存在三个明显缺陷一是需要额外工具分析二是缺乏业务上下文三是无法主动上报。我们团队在线上服务维护中经常遇到凌晨崩溃后只能拿到一个模糊的core文件要花费数小时才能定位到具体问题场景。Google的Glog日志库原生支持信号处理signal handler但默认实现有两个不足首先它只处理SIGSEGV等少数几种信号其次崩溃日志与业务日志混在一起不利于后续分析。这促使我们对Glog进行二次封装实现更完善的崩溃信号捕获体系。2. 信号处理机制深度解析2.1 Linux信号系统工作原理当程序发生段错误SIGSEGV、浮点异常SIGFPE等严重错误时操作系统会向进程发送对应的信号。如果没有注册处理函数系统会执行默认行为通常是终止进程。通过sigaction()系统调用我们可以注册自定义处理函数在崩溃发生时接管控制流。关键信号列表信号值信号名触发场景6SIGABRT调用abort()函数触发8SIGFPE算术运算错误如除零11SIGSEGV非法内存访问空指针解引用15SIGTERM终止请求kill默认信号2.2 Glog原生信号处理实现Glog通过InstallFailureSignalHandler()函数注册信号处理器核心逻辑在DumpSignalHandler()函数中。其工作流程为捕获信号后立即阻塞其他信号记录堆栈回溯信息到日志文件调用原始信号处理器通常导致进程退出存在的问题是仅处理6/8/11/15四种信号堆栈信息未符号化需要addr2line二次处理无法区分不同线程的崩溃场景3. 增强型封装实现方案3.1 信号处理器注册增强我们扩展了信号注册范围并添加线程局部存储TLS支持const std::vectorint kCrashSignals { SIGSEGV, SIGABRT, SIGFPE, SIGILL, SIGBUS, SIGTRAP, SIGSYS, SIGXCPU }; void RegisterSignalHandlers() { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_sigaction EnhancedSignalHandler; sa.sa_flags SA_SIGINFO | SA_ONSTACK; for (int sig : kCrashSignals) { if (sigaction(sig, sa, nullptr) 0) { LOG(ERROR) Failed to register handler for signal sig; } } }关键改进点新增SIGBUS(7)/SIGILL(4)等硬件异常信号使用SA_SIGINFO标志获取更多上下文信息每个线程维护独立的信号栈避免栈溢出时无法处理3.2 增强型信号处理函数核心处理逻辑包含四个关键步骤void EnhancedSignalHandler(int sig, siginfo_t* info, void* ucontext) { // 1. 立即刷新所有缓存日志 google::FlushLogFiles(google::GLOG_INFO); // 2. 记录基础信息 LogCrashHeader(sig, info); // 3. 获取符号化堆栈 std::vectorstd::string stack GetSymbolizedStackTrace(ucontext); // 4. 写入专用崩溃日志文件 WriteCrashLog(stack, GetThreadSpecificContext()); // 5. 执行原始处理逻辑 CallOriginalHandler(sig); }其中GetSymbolizedStackTrace()的实现要点通过libunwind获取调用栈地址使用dladdr()解析动态库符号缓存符号查询结果提升性能4. 生产环境实践技巧4.1 日志文件分离策略我们建议采用三级日志分离方案logs/ ├── app_info.20240315.log # 常规业务日志 ├── crash.20240315.log # 崩溃专用日志 └── metric.20240315.log # 性能指标日志在Glog初始化时配置google::SetLogDestination(google::INFO, logs/app_info.); google::SetLogDestination(google::ERROR, logs/crash.); FLAGS_logbufsecs 0; // 立即刷新日志4.2 堆栈解析优化对于大型C项目推荐在编译时添加调试信息# CMake配置示例 set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -g -fno-omit-frame-pointer)同时部署addr2line缓存服务class SymbolCache { public: std::string Resolve(const void* addr) { auto it cache_.find(addr); if (it ! cache_.end()) return it-second; std::string result RunAddr2Line(addr); cache_[addr] result; return result; } private: std::unordered_mapconst void*, std::string cache_; };5. 典型问题排查指南5.1 信号处理器递归调用当信号处理函数本身触发异常时会导致无限递归。我们的解决方案使用sigaltstack()设置独立信号栈在handler入口处检查递归标记__thread bool in_handler false; void SafeSignalHandler(...) { if (in_handler) _exit(1); in_handler true; // 实际处理逻辑 }5.2 多线程环境下的竞争条件对于线程池场景需要特别注意每个工作线程初始化时注册信号栈使用pthread_sigmask()阻塞信号传递主线程单独处理SIGTERM等管理信号实测案例某次线程池任务中频繁发生SIGSEGV最终发现是因为工作线程未设置信号掩码导致信号被随机线程捕获。6. 高级应用场景扩展6.1 崩溃时保存业务快照我们在电商系统中扩展了崩溃处理器能在程序退出前保存购物车状态void SaveCartSnapshot() { try { auto cart ShoppingCart::GetThreadInstance(); cart.SerializeToFile(/tmp/cart_snapshot.bin); } catch (...) {} // 确保不影响崩溃流程 } // 注册为崩溃回调 AddCrashCallback(SaveCartSnapshot);6.2 结合minidump生成对于Windows跨平台项目可集成Breakpadvoid GenerateMinidump(ucontext_t* context) { google_breakpad::ExceptionHandler eh( /tmp, nullptr, nullptr, nullptr, true); eh.WriteMinidumpForContext(context); }7. 性能影响实测数据在4核8G的测试服务器上对不同方案进行压力测试方案正常请求QPS崩溃恢复时间日志完整性原生Glog125002.1s部分丢失基础封装版12100 (-3%)1.8s完整带符号缓存的高级版11900 (-5%)1.5s完整符号关键发现信号处理器的性能损耗主要来自堆栈展开和符号解析建议在生产环境开启符号缓存