刚进入函数时什么会导致段错误？

输入的函数如下所示:

21:  void eesu3(Matrix & iQ)
22:  {

其中 Matrix 是一个 struct。当使用 GDB 运行时，回溯产生:

(gdb) backtrace 
#0  eesu3 (iQ=...) at /home/.../eesu3.cc:22
#1  ...

GDB 没有说明什么是iQ。 ... 确实存在。 什么会导致这个？

海湾合作委员会:(Ubuntu/Linaro 4.6.3-1ubuntu5)4.6.3

使用-O3 -g构建的程序

来电者是这样的:

Matrix q;
// do some stuff with q
eesu3(q);

这里没什么特别的

我用 valgrind 重新运行程序:

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes <prgname>

输出:

==2240== Warning: client switching stacks?  SP change: 0x7fef7ef68 --> 0x7fe5e3000
==2240==          to suppress, use: --max-stackframe=10076008 or greater
==2240== Invalid write of size 8
==2240==    at 0x14C765B: eesu3( Matrix &) (eesu3.cc:22)
...
==2240==  Address 0x7fe5e3fd8 is on thread 1's stack
==2240== 
==2240== Can't extend stack to 0x7fe5e2420 during signal delivery for thread 1:
==2240==   no stack segment
==2240== 
==2240== Process terminating with default action of signal 11 (SIGSEGV)
==2240==  Access not within mapped region at address 0x7FE5E2420
==2240==    at 0x14C765B: eesu3( Matrix&) (eesu3.cc:22)
==2240==  If you believe this happened as a result of a stack
==2240==  overflow in your program's main thread (unlikely but
==2240==  possible), you can try to increase the size of the
==2240==  main thread stack using the --main-stacksize= flag.
==2240==  The main thread stack size used in this run was 8388608.

看起来它是一个损坏的堆栈。

    Dump of assembler code for function eesu3( Matrix & ):
   0x00000000014c7640 <+0>: push   %rbp
   0x00000000014c7641 <+1>: mov    %rsp,%rbp
   0x00000000014c7644 <+4>: push   %r15
   0x00000000014c7646 <+6>: push   %r14
   0x00000000014c7648 <+8>: push   %r13
   0x00000000014c764a <+10>:    push   %r12
   0x00000000014c764c <+12>:    push   %rbx
   0x00000000014c764d <+13>:    and    $0xfffffffffffff000,%rsp
   0x00000000014c7654 <+20>:    sub    $0x99b000,%rsp
=> 0x00000000014c765b <+27>:    mov    %rdi,0xfd8(%rsp)

好吧，说清楚一点:Matrix 的数据存在于堆中。它基本上包含一个指向数据的指针。该结构很小，只有 32 个字节。 (刚刚检查过)

现在，我用不同的优化选项重建了程序:

-O0:错误不显示。

-O1:确实显示错误。

-O3:确实显示错误。

--更新

-O3 -fno-inline -fno-inline-functions: 错误不显示。

这就解释了。函数内联过多导致堆栈使用过多。

问题是由于堆栈溢出

最佳答案

What can cause a segmentation fault when just entering a function?

最常见的原因是堆栈耗尽。做(gdb) disas在崩溃点。如果崩溃的指令是在 %rsp 之后第一次读取或写入堆栈位置已经递减，那么堆栈耗尽几乎肯定是原因。

解决方案通常涉及创建具有更大堆栈的线程，将一些大变量从堆栈移动到堆，或两者兼而有之。

另一个可能的原因:如果Matrix包含非常大的数组，您不能将它放在堆栈上:内核不会将堆栈扩展到当前堆栈之外超过 128K(大约，我不记得确切的值)。如果Matrix大于这个限制，你不能把它放在堆栈上。

更新:

   0x00000000014c7654 <+20>:    sub    $0x99b000,%rsp
=> 0x00000000014c765b <+27>:    mov    %rdi,0xfd8(%rsp)

这个反汇编证实了诊断。

此外，您在堆栈上保留了 0x99b000 字节(几乎是 10MB)。在 eesu3 中一定有一些您试图在堆栈上定位的巨大对象常规。不要那样做。

What do you mean by "the kernel will not extend stack beyond current by more than"

当您扩展堆栈(递减 %rsp )时，例如1MB，然后尝试触摸该堆栈位置，内存将不可访问(内核按需增长堆栈)。这将生成一个硬件陷阱，并将控制权转移到内核。当内核决定做什么时，它会查看

1. 当前 %rsp
2. 应用程序试图访问的内存位置
3. 当前线程的堆栈限制

如果故障地址低于当前 %rsp ，但在 128K(或其他类似大小的常量)内，内核只是扩展堆栈(前提是这种扩展不会超过堆栈限制)。

如果故障地址比当前地址低 128K 以上 %rsp (就像这里的情况一样)，你得到 SIGSEGV .

这对大多数程序来说都很好:即使它们在递归过程中使用大量堆栈，它们通常也会以小块的形式扩展堆栈。但是试图在单个例程中保留所有堆栈的等效程序会崩溃。

无论如何，做(gdb) info locals在崩溃点，看看本地人可能需要 10MB 的堆栈。然后将它们移动到堆中。

更新 2:

No locals

啊，程序可能还没有进入 eesu3因为有本地人。

when building with -O0 the error disappears. GCC bug?

这可能是 GCC 错误，但更有可能是 GCC 将许多其他例程内联到 eesu3 中。 ，并且每个内联例程都需要自己的 N KB 堆栈。如果构建包含 eesu3 的源代码，问题是否会消失？与 -fno-inline ？

不幸的是，对此类行为进行分类并找出适当的解决方法或修复 GCC，需要编译器专业知识。您可以先使用 -fdump-tree-all 进行编译并查看生成的 <source>.*t.*文件。这些包含编译过程各个阶段的 GCC 内部表示的文本转储。您可能能够充分理解它以取得进一步的进步。

关于c++ - 输入函数时的 SIGSEGV，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10499400/