3

或者只是一般的调试，你喜欢如何去寻找代码中的错误。特别适用于 C/C++，但一般适用于所有语言。我一直在试图找出这个令人讨厌的段错误的原因，但我希望自己找到它，而不是在网上发布它。你对像我这样的学徒有什么建议吗？

4

6 回答 6

1

尝试将您的代码推入糟糕的情况。

如果您正在编写解析器，请将 BMP、JPG、随机文本扔给它，然后看看会发生什么。如果你正在编写一个 RPC 协议服务器，用大量并发请求使其超载，向其中写入垃圾，在不知名的地方断开客户端......

一开始不要狡猾，尽可能地抛出，然后尝试欺骗你的代码。

于 2013-06-20T15:00:49.753 回答
1
  1. 用 GCC 的调试 flash 编译
  2. 使用您的 exe 启动 gdb
  3. r（如果需要，带参数）
  4. BT

该解决方案通常允许识别段错误及其原因。

于 2013-06-20T13:51:14.923 回答
1

使用诸如 gdb 之类的调试器并在段错误时打印回溯。它将显示崩溃的行号和文件。以此为起点。

为了更进一步，您可以重复该过程以确保它不是由于更早的其他错误而发生的随机故障，而是该行号的特定问题。

对于静态代码分析，您可以使用诸如klockworks 或 lint 之类的工具来显示代码中可能存在的问题。

对于动态分析，请使用诸如memwatch 之类的工具，它可以在运行时监控您的内存分配。

我没有指出 valgrind，因为其他人已经提到过它，毫无疑问它是一个很棒的工具。

于 2013-06-20T13:48:54.270 回答
0

RMS 为使用 gdb 查找段错误做了一个很好的教程。

精简版：

$ gcc -g -O0 -o program program.c # -O0 makes debugging easier
$ gdb ./program
> run # Tell gdb to start running the thing
...segfault happens
> bt # Get a stack trace from where it segfaulted
于 2014-01-30T15:22:16.803 回答
0

我通常在调试器中运行......通常有足够的线索可以继续追踪它......调用堆栈，变量的当前状态等。如果堆栈被丢弃或堆损坏，它可能会更加困难。如果我有一个可重复的场景，我将在 valgrind (Linux) 中运行它，它会检查所有内容并经常查明问题。

于 2013-06-20T13:49:13.050 回答
0

如果您在一个花哨的 IDE 中尝试熟悉断点，您可以使用它们来查看在发生段错误之前您对代码的了解程度。如果您没有该选项，最简单的方法是一次注释掉部分代码，直到您发现有问题为止。

我发现注释掉方法对于在小型作业大小的 C 问题中查找段错误非常有效。

于 2013-06-20T13:52:10.130 回答