甚至在执行“main()”第一行并且没有非局部变量之前就出现分段错误

Dav*_*ave 2 c++ segmentation-fault c++14

main()在下面的 C++ 代码中,在执行第一行之前发生分段错误。
即使在输入之前没有要构造的对象,也会发生这种情况main(),并且如果我删除 .txt 文件第二行的(大)变量定义,则不会发生这种情况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];
}
Run Code Online (Sandbox Code Playgroud)
  • 操作系统:CentOS Linux 版本 7.9.2009(核心)
  • 编译器:g++(GCC)7.3.1 20180303(红帽7.3.1-5)
  • 编译命令:
g++ -std=c++14 -Wall -Wpedantic -Og -g -o create_hand_map create_hand_map.cpp
Run Code Online (Sandbox Code Playgroud)

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

静态分析:

通过 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]
Run Code Online (Sandbox Code Playgroud)

尝试使用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)
Run Code Online (Sandbox Code Playgroud)

Nat*_*dge 5

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

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

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

在这种情况下,发生的事情如下。

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

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

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

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

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


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