【问题标题】:Bizarre/Random Segfault in CC中的奇怪/随机段错误
【发布时间】:2010-12-26 02:29:30
【问题描述】:

编辑:澄清。

  • fout 是一个文件*。 (我认为这无关紧要,因为该行清楚地编译)
  • 最后几行上面有很多代码;我想我可以把它们都扔掉,但我想你对调试我的东西并不太感兴趣。通常,我更感兴趣的是在返回 0 时可能发生的段错误,但之前不会发生。

警告:我的 C 很糟糕。

我有一个 C 程序,就像它一样,它只是 想要 出现段错误。其他不相关的细节我就不说了,但这是大局:

我的代码:

//...other code
printf("finished \n");   
fclose(fout);   
printf("after fclose \n");  
return 0;

输出:

完成
关闭后
分段错误

我正在使用 GCC 进行编译,-std=c99。

我的问题:

这怎么可能?我应该看什么,这可能导致这个(看似随机的)段错误?有什么想法吗?

非常感谢!

【问题讨论】:

  • 那些“细节”并非“无关紧要”。
  • fout 是什么?有人给它分配了stdout 吗?
  • 你知道,如果你以两个空格结束一行,它会在下一行之前添加一个强制换行符,如果你缩进一个有四个空格的文本块,它会预先格式化它。

标签: c segmentation-fault


【解决方案1】:

无论return 返回到什么位置都会导致故障。如果此代码 sn-p 在main() 中,则该代码已对堆栈造成损坏,很可能是超出了变量的界限。例如

int main ()
{
    int a [3];
    int j;

    for (j = 0;  j < 10;  ++j)
         a [j] = 0;
    return 0;
}

这类事情可能会导致许多莫名其妙的症状中的任何一种,包括段错误。

【讨论】:

  • 谢谢!这基本上是我想要达到的。好的,太好了。
  • 使用 GDB 将允许您立即定位段错误,还允许您仔细阅读堆栈以定位任何可能不可靠的值。
  • 我现在正在阅读一些 GDB 教程。但是如果我的程序最后只出现段错误,我应该在上面寻找什么?有什么推荐的技术吗?
  • 先看看是什么操作导致了 GDB 中的段错误。没有它,您将无法走得更远。只需执行 gdb your-app 启动时,键入run,然后在段错误后键入backtrace 以检查堆栈。您不需要了解更多关于 gdb 的信息。
  • 如果原因确实是破坏堆栈,GDB 将显示一个看起来混乱的堆栈。这可能根本没有任何意义。
【解决方案2】:

由于这可能是与堆栈损坏相关的问题,您还可以使用内存调试器来定位损坏源,例如 valgrind
只需使用gcc -g 编译,然后运行valgrind yourprog args

【讨论】:

  • 谢谢!后来我自己发现了这个。 valgrind 很棒。
【解决方案3】:

“世界你好!”程序段错误?如果是这样,那么您有硬件问题。如果不是,那么您没有向我们展示的代码中至少有一个问题!

【讨论】:

    【解决方案4】:

    使用调试标志gcc -g 编译您的程序并在gdb 中运行您的代码。您不能总是相信控制台会在执行有问题的代码或相对于其他输出时准确地输出“分段错误”。在许多情况下,这会产生误导——您会发现诸如gdb 之类的调试工具非常有用。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-05-13
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多