c++ - 甚至在执行第一行 `main()` 之前就出现段错误，并且没有非局部变量

Question

在下面的 C++ 代码中，段错误发生在 main() 第一行之前已执行。
即使在输入 main() 之前没有要构造的对象，也会发生这种情况如果我删除 main() 第二行的(大)变量定义，则不会发生这种情况。 .

我假设由于定义的变量的大小而发生段错误。我的问题是为什么会在执行之前行之前发生这种情况？

由于优化器对指令进行了重新排序，这种情况似乎不应该发生。我这样说是基于所选的编译选项和调试输出。
定义的(数组)变量的大小是否会破坏堆栈/导致段错误？
看起来确实如此，因为使用较小的数组(例如 15 个元素)不会导致段错误，并且可以看到标准输出的预期输出。

#include <array>
#include <iostream>
#include <vector>

using namespace std;

namespace {
using indexes_t = vector<unsigned int>;
using my_uint_t = unsigned long long int;

constexpr my_uint_t ITEMS{ 52 };
constexpr my_uint_t CHOICES{ 5 };
static_assert(CHOICES <= ITEMS, "CHOICES must be <= ITEMS");

constexpr my_uint_t combinations(const my_uint_t n, my_uint_t r)
{
    if (r > n - r)
        r = n - r;

    my_uint_t rval{ 1 };

    for (my_uint_t i{ 1 }; i <= r; ++i) {
        rval *= n - r + i;
        rval /= i;
    }

    return rval;
}

using hand_map_t = array<indexes_t, combinations(ITEMS, CHOICES)>;

class dynamic_loop_functor_t {
private:
    // std::array of C(52,5) = 2,598,960 (initially) empty vector<unsigned int>
    hand_map_t hand_map;
};
}

int main()
{
    cout << "Starting main()..." << endl
         << std::flush;

    // "Starting main()..." is not printed if and only if the line below is included.
    dynamic_loop_functor_t dlf;

    // The same result occurs with either of these alternatives:
    // array<indexes_t, 2598960> hand_map;
    // indexes_t hand_map[2598960];
}

• 操作系统:CentOS Linux 版本 7.9.2009(核心)
• 编译器:g++ (GCC) 7.3.1 20180303(Red Hat 7.3.1-5)
• 编译命令:

g++ -std=c++14 -Wall -Wpedantic -Og -g -o create_hand_map create_hand_map.cpp

编译时不会生成任何错误或警告。

静态分析:

通过 cppcheck 进行的静态分析不会产生意外结果。 按照下面的命令输出中的建议使用 check-config 只会产生:Please note: Cppcheck does not need standard library headers to get proper results.

$ cppcheck --enable=all create_hand_map.cpp
create_hand_map.cpp:136:27: style: Unused variable: dlf [unusedVariable]
   dynamic_loop_functor_t dlf;
                          ^
nofile:0:0: information: Cppcheck cannot find all the include files (use --check-config for details) [missingIncludeSystem]

尝试使用 GDB 进行调试:

$ gdb ./create_hand_map
GNU gdb (GDB) Red Hat Enterprise Linux 8.0.1-36.el7
<snip>
This GDB was configured as "x86_64-redhat-linux-gnu".
<snip>
Reading symbols from ./create_hand_map...done.
(gdb) run
Starting program: ./create_hand_map

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400894 in std::operator<< <std::char_traits<char> > (__s=0x4009c0 "Starting main()...",
    __out=...) at /opt/rh/devtoolset-7/root/usr/include/c++/7/ostream:561
561             __ostream_insert(__out, __s,
(gdb) bt
#0  0x0000000000400894 in std::operator<< <std::char_traits<char> > (
    __s=0x4009c0 "Starting main()...", __out=...)
    at /opt/rh/devtoolset-7/root/usr/include/c++/7/ostream:561
#1  main () at create_hand_map.cpp:133
(gdb)

Answer 1

这绝对是堆栈溢出。 sizeof(dynamic_loop_functor_t)接近 64 MiB，大多数 Linux 发行版上的默认堆栈大小限制仅为 8 MiB。所以崩溃并不奇怪。

剩下的问题是，为什么调试器将崩溃识别为来自内部 std::operator<< ？实际的段错误是由第一条访问超出堆栈限制的地址的指令引发的 CPU 异常引起的。调试器仅获取错误指令的地址，并且必须使用编译器提供的调试信息将其与特定的源代码行关联起来。

这个过程的结果并不总是直观的。指令和源代码行之间并不总是存在明确的对应关系，特别是当优化器可能重新排序指令或组合来自不同行的代码时。此外，在很多情况下，一个源代码行的错误或问题可能会导致另一部分代码出现错误，而这些代码原本是无辜的。因此，应该始终对调试器显示的源代码行持保留态度。

在这种情况下，发生的情况如下。

• 编译器确定所有局部变量所需的堆栈空间总量，并通过从函数开头的堆栈指针中减去该数字来分配它，在 prologue 中。 。这比在声明时为每个局部变量进行单独分配更有效。 (请注意，构造函数(如果有)在代码中实际出现变量声明的位置之前不会被调用。)

  序言代码通常不与任何特定的源代码行相关联，或者可能与包含函数开头 { 的行相关联。 。但无论如何，从堆栈指针中减去是纯粹的寄存器操作；它不访问内存，因此本身不会导致段错误。尽管如此，堆栈指针现在指向堆栈映射的区域之外，因此下次尝试访问堆栈指针附近的内存将出现段错误。

• main接下来的几条指令执行cout << "Starting main" 。从概念上讲，这是对重载的 operator<< 的调用。来自标准库；但在 GCC 的 libstdc++ 中，operator<<是一个非常短的函数，仅调用名为 __ostream_insert 的内部辅助函数。由于它太短，编译器决定内联 operator<<进入main ，等等main实际上包含对 __ostream_insert 的调用。这是出错的指令:x86 call指令将返回地址压入堆栈，并且如上所述，堆栈指针超出范围。

  现在是设置参数并调用 __ostream_insert 的指令被调试信息标记为对应于 operator<< 的源，在 <ostream>头文件 - 即使这些指令已内联到 main 中。因此，您的调试器将崩溃显示为发生在“内部”operator<< .

  编译器未内联 operator<< (例如，如果您在没有优化的情况下进行编译)，则 main将包含对 operator<< 的实际调用，而这个调用就会崩溃。在这种情况下，回溯将指向 cout << "Starting main"线路 main本身 - 以不同的方式误导。

---

请注意，您可以让 GCC 通过选项 -Wstack-usage=NNN 警告您有关使用大量堆栈的函数。或-Wframe-larger-than=NNN 。 -Wall 未启用这些功能，但添加到您的构建中可能很有用，特别是如果您希望使用大型本地对象。指定其中任何一个，并使用合理的数字 NNN (比如 4000000)，我在您的 main 上收到警告功能。