升级GCC版本导致程序崩溃：代码不规范的隐患

在同一段业务代码的情况下，程序在 CentOS 7 环境下编译并运行正常，但当切换到 CentOS 8 并使用更新版的 GCC 进行编译时，程序却发生了崩溃。值得注意的是，问题只在 Release 模式下出现，Debug 模式则完全没有问题。这是我们第一次遇到类似的情况，经过三天的排查，最终找到了问题的根源。

问题定位

通过一番排查，问题的症结在于 函数缺少返回值。在 Release 模式下，GCC 新版本会进行更多的优化，这导致了原本没有显式返回值的函数在执行过程中出现了未知的逻辑，从而引发了崩溃。我们的结论是，编译器的警告不容忽视，尤其是在老项目中，部分警告可能被无视，但也应当避免屏蔽所有警告。

环境说明

CentOS 7 GCC版本：

gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright © 2015 Free Software Foundation, Inc.

CentOS 8 GCC版本：

gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-21)
Copyright (C) 2018 Free Software Foundation, Inc.

崩溃现象

我们在分析程序崩溃的堆栈时，看到的堆栈信息如下：

[New LWP 1385902]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./pstack_main`.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ffe894b4420 in ?? ()
(gdb) bt
#0  0x00007ffe894b4420 in ?? ()
#1  0x00000000004008e9 in main ()

这个堆栈看上去并不直观，崩溃函数的栈信息居然显示为一个 ??，这让问题的排查变得更加复杂。

代码示例

为了更好地理解问题，下面是重现崩溃的最小代码示例：

#include <iostream>
#include <map>

int test() {
    std::cout << "1" << std::endl;
}

int main() {
    test();
    return 0;
}

该代码中的 test() 函数显然没有显式返回一个值，而它的返回类型是 int。根据 C++ 规范，当一个函数声明为 int 类型时，必须有一个返回值，否则就可能导致未定义行为。

编译警告

在我们的项目中，CMake 脚本屏蔽了许多编译时警告，其中就包括了以下警告信息：

/root/pstack/main.cpp: In function ‘int test()’:
/root/pstack/main.cpp:7:1: warning: no return statement in function returning non-void [-Wreturn-type]

这一警告表明 test() 函数没有返回值，而这正是问题的根源。高版本的 GCC（如 8.5.0）在优化代码时可能会对这种未定义的行为做出不稳定的优化，从而导致程序崩溃。

汇编代码差异

为了解释 GCC 编译器优化行为的差异，我们对比了不同版本 GCC 生成的汇编代码：

GCC 4.8.5 生成的汇编代码：

汇编代码较为冗长，且包含了对标准输出流（如 std::cout）的处理逻辑。这表明编译器进行了更保守的优化，未对 test() 函数中缺失返回值的问题做过多优化，可能因此避免了崩溃。
GCC 8.5.0 生成的汇编代码：

新版本的 GCC 进行了更多的优化，减少了代码量。然而，这种优化可能使得缺少返回值的函数执行时行为不确定，从而导致程序崩溃。

结论

通过这次问题排查，我们深刻认识到，在 C++ 中，函数返回值必须明确，特别是在函数声明为 int 时，必须提供一个返回值。对于使用较旧版本编译器的项目，升级到新版本的 GCC 时，可能会遇到更多的优化和更严格的警告机制。因此，我们建议在编译时 不要屏蔽所有警告，而是应该有选择性地处理它们，尤其是函数返回值、类型匹配等常见问题。

最终，通过为 test() 函数添加一个返回值，问题得以解决，程序恢复了正常的运行。