你找到段错的原因是什么？
或者只是调试一般，你如何去寻找代码中的bug。 特别适用于C / C ++，但一般来说都是所有语言。 我一直试图找到这个令人讨厌的段错误的原因，但我喜欢自己找到它的挑战，而不是在网上发布它。 你对像我这样的padawan有什么建议吗？
使用调试器（如gdb）和seg fault，打印回跟踪。 它会显示崩溃的行号和文件。 以此为出发点。
为了更进一步，你可以重复这个过程，以确保它不是一个随机的错误，由于其他地方的错误，而在那个行号更具有特定问题。
对于静态代码分析，您可以使用klockworks或lint等工具来显示代码中可能存在的问题。
对于动态分析 ，请使用memwatch等工具来监视运行时的内存分配。
我没有指出valgrind，因为它已被其他人提及，毫无疑问是一个很好的工具。
- 使用GCC的调试闪存进行编译
- 用你的exe启动gdb
- r（如果需要，带参数）
- BT
该解决方案通常允许识别段错误及其原因。
尝试将代码推送到糟糕的情况。
如果你正在编写一个解析器，抛出BMP，JPG，随机文本，看看会发生什么。 如果您正在编写RPC协议服务器，请将大量并发请求重载，将垃圾写入其中，在不知道的地方断开客户端连接…
一开始不要微妙，扔掉任何可能的东西，然后尝试欺骗你的代码。
我通常在调试器中运行…通常有足够的线索继续追踪它…调用堆栈，变量的当前状态等。如果堆栈被破坏或堆损坏，则可能更难。 如果我有一个可重复的场景，我将在valgrind（Linux）中运行它，它会检查所有内容，并且经常可以查明问题。
如果您在花哨的IDE中尝试熟悉断点，可以使用它们来查看在segfault发生之前您进入代码的距离。 如果您没有该选项，最简单的方法是一次一个地注释掉部分代码，直到找到破坏的内容。
我发现注释方法对于在小作业大小的C问题中找到段错误非常有效。
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