glog致命错误栈追踪解析：从崩溃日志到问题解决

18次阅读

在C++开发中，使用glog日志库时遇到程序崩溃，控制台打印的栈追踪信息往往是定位问题的关键。最近有开发者反馈了一段glog崩溃栈追踪，今天就以此为例，手把手教大家读懂栈信息、定位根源、快速修复，帮大家避开这类常见坑。

一、先看崩溃栈追踪：读懂每一行的含义

先贴出本次的崩溃栈追踪信息，我们逐行拆解，搞懂每一行背后的意义：

Check failure stack trace: ***
    @          0x1e36e8d  google::LogMessage::Fail()
    @          0x1e38ba1  google::LogMessage::SendToLog()
    @          0x1e36a82  google::LogMessage::Flush()
    @          0x1e391a9  google::LogMessageFatal::~LogMessageFatal()
    @           0xeccaeb  main
    @     0x708a927397b3  __libc_start_main
    @          0x108dcce  (unknown)

很多开发者看到这段信息会慌，觉得全是陌生的地址和函数，其实核心信息很明确，我们拆解重点：

google::LogMessage::Fail()：glog库检测到错误，触发失败逻辑，这是崩溃的起始点，但不是根源。
google::LogMessageFatal::~LogMessageFatal()：关键函数！表示触发了glog的FATAL级别日志——glog中FATAL级日志会直接终止程序，这是程序崩溃的直接原因。
main：重中之重！栈追踪显示崩溃根源在main函数（地址0xeccaeb处），不是glog库本身的问题，而是我们自己的代码触发了致命错误。
__libc_start_main：系统启动函数，无关核心问题，可忽略；(unknown)表示无法解析的地址，通常不影响问题定位。

核心结论：程序崩溃不是glog库 bug，而是 main 函数中某行代码，触发了glog的FATAL级日志检查，导致程序强制退出。

二、glog FATAL崩溃的4种常见根源（99%命中）

glog的FATAL日志不会轻易触发，只有遇到“严重错误且无法恢复”的情况才会终止程序，结合日常开发经验，最常见的原因有4种，按出现频率排序：

1. 断言检查失败（最常见）

这是最主要的原因！我们在代码中使用glog的CHECK系列宏（如CHECK、CHECK_EQ、CHECK_NE等）做参数校验、指针非空校验等，当校验条件不满足时，就会触发FATAL日志，直接崩溃。

示例代码（错误示范）：

#include <glog/logging.h>
int main(int argc, char* argv[]) {
    google::InitGoogleLogging(argv[0]);
    int* ptr = nullptr;
    // 断言ptr非空，若为空则触发FATAL崩溃
    CHECK(ptr != nullptr) << "ptr指针为空，无法继续执行";
    return 0;
}

当ptr为空时，就会打印类似“Check failed: ptr != nullptr ptr指针为空，无法继续执行”的日志，随后出现本文开头的栈追踪。

2. 手动触发FATAL日志

部分开发者会在代码中主动使用LOG(FATAL)打印致命错误，用于处理无法恢复的异常场景，这种情况会直接终止程序。

示例代码：

LOG(FATAL) << "配置文件加载失败，程序无法启动"; // 直接触发崩溃

3. 内存错误（空指针、越界等）

当代码中存在空指针解引用、数组越界等内存错误时，可能会触发glog内部的安全检查，进而打印FATAL日志并崩溃。这种情况通常伴随内存访问异常，需要结合调试定位。

4. glog初始化或配置错误

glog未正确初始化（如未调用google::InitGoogleLogging(argv[0])）、日志输出目录无读写权限、日志文件无法创建等，也会导致FATAL崩溃，但这种情况多发生在程序启动初期。

三、3步快速定位问题（新手也能上手）

拿到栈追踪后，不用慌，按以下步骤操作，快速找到崩溃的具体代码行，效率翻倍：

步骤1：找到完整的崩溃日志（最关键）

很多开发者只贴了栈追踪，却忽略了栈追踪上方的错误描述——这才是定位问题的核心！glog在打印栈追踪前，会先打印“Check failed: 条件错误信息”，示例：

E0509 10:00:00.000000  12345 main.cpp:15] Check failed: ptr != nullptr ptr指针为空，无法继续执行
Check failure stack trace: ***
@          0x1e36e8d  google::LogMessage::Fail()
...（后续栈追踪）

这一行直接告诉我们3个关键信息：① 崩溃文件（main.cpp）；② 崩溃行号（15行）；③ 错误原因（ptr指针为空），有了这些，基本能直接定位问题。

步骤2：编译带调试信息，重新运行

如果日志中没有显示行号（比如只显示地址），说明编译时没有添加调试信息，需要重新编译程序，添加-g参数（gcc/g++），生成带调试信息的可执行文件：

# g++编译示例（替换为你的文件名和依赖）
g++ -g -o your_program your_code.cpp -lglog

# 运行程序，此时日志会显示精确行号
./your_program

步骤3：用gdb调试（精准定位）

如果以上方法仍无法定位，用gdb调试工具，直接查看崩溃时的函数调用栈和具体代码，步骤如下：

# 启动gdb，关联可执行文件
gdb ./your_program

# 运行程序，等待崩溃
run

# 崩溃后，输入bt查看完整调用栈（会显示具体行号）
bt

输入bt后，会清晰显示崩溃在main函数的哪一行，以及当前的变量值，轻松定位问题。

四、快速修复方案（对应常见原因）

找到问题后，针对性修复，以下是对应4种常见原因的修复建议，直接套用即可：

断言失败：修改CHECK宏的条件，确保校验逻辑正确；若允许程序继续执行，可将CHECK改为CHECK_OK（非致命），或用LOG(ERROR)替代，同时处理异常场景。
手动触发FATAL：检查触发LOG(FATAL)的场景，判断是否可以改为LOG(ERROR)，并添加异常处理逻辑，避免程序直接崩溃；若确实是无法恢复的错误，需修复触发该错误的根源（如配置文件、依赖等）。
内存错误：修复空指针、数组越界等问题，可使用valgrind工具检测内存泄漏或访问异常，命令：valgrind –leak-check=full ./your_program。
glog配置错误：确保程序启动时调用google::InitGoogleLogging(argv[0])；检查日志输出目录（默认/tmp）是否有读写权限，若需自定义目录，可添加配置：google::SetLogDestination(google::GLOG_INFO, “./log/”)。