0

有人可以解释为什么这个“无尽的”循环会很快出现段错误吗？例如，假设我们有这个功能：

#!/bin/bash

foo() {
  foo 
}; foo

这会在8-10秒后出现段错误。通过 strace 检查，我们可以看到很多brk()调用：

brk(0x2e11000)                          = 0x2e11000
brk(0x2e12000)                          = 0x2e12000
brk(0x2e13000)                          = 0x2e13000
brk(0x2e14000)                          = 0x2e14000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffcddf5ff68} ---
+++ killed by SIGSEGV +++
Segmentation fault

我的问题是：

  1. 这是因为它试图访问内存空间中的未映射区域（通过 brk）而导致段错误吗？
  2. 如果是，为什么要尝试访问它？
  3. malloc() 在这里会是更好的选择吗？
  4. 如果您对此有任何额外/琐事信息，我们将不胜感激。
4

2 回答 2

3

  1. brks 不相关。它会出现段错误，因为它耗尽了堆栈空间。如果您减少可用堆栈，ulimit -s 512; ./yourscript您会发现它崩溃得更快。

  2. 它吞噬了所有堆栈空间，因为您有一个无限递归函数，而 bash 不进行尾调用优化。

  3. 它已经使用malloc（或其特定的 bash 版本）。由于malloc是 C 库函数而不是系统调用，因此它不会出现在strace. 但是分配的内存没有问题，它的堆栈空间用完了。

  4. s 用于存储与无限递归相关的brk一些无限元数据，但这还不够重要。

    当您有未优化的无限递归时，无限递归函数的崩溃以各种形式在所有语言中发生。尝试void foo() { foo(); }使用 Java 或def foo(): foo()Python。

于 2017-12-28T18:18:49.987 回答
0

看起来您看到的是堆栈不断增长，直到资源耗尽。简而言之，这是一个递归问题。

看一下brk()调用，您会发现它正在更改进程数据段的结尾。增加程序中断是为进程分配内存，但您没有取之不尽的供应。当你用完时，它会崩溃。

但是对于您的第三个问题，即使文档中的注释部分也表明 malloc() 是更好的选择。

于 2017-12-28T18:10:52.877 回答