分段错误 - 如何调试？ [关闭]

Posted 2021-04-16

我的应用程序崩溃了，它在控制台上打印如下：

sh [366]：/ bin / sh：第1行：367分段错误（核心转储）./ myapp

我的问题是这里367表示什么？

我无法在任何地方找到核心转储文件。 任何线索如何在这种情况下调试分段错误？

答案

367是一个进程ID（程序segfaulting）。您可以在gdb调试器下运行您的程序。

阅读How To Debug Small Programs然后documentation of gdb。考虑也使用valgrind。

任何线索如何在这种情况下调试分段错误？

如果该故障是可重现的，那很容易。在gdb下运行您的程序

我无法在任何地方找到核心转储文件..

仔细阅读core(5)（和getrlimit(2);也许核心转储已被禁用，例如一些ulimit bash builtins）。您的系统可能已配置（请参阅proc(5)）以其他方式转储核心（例如，通过systemd(1)，可能在/var/lib/systemd/coredump/下）。也许看看coredumpctl(1)和systemd-coredump(8)以及coredump.conf(5)

在编译应用程序时，不要忘记启用所有警告和调试信息with g++ -Wall -Wextra -g（当然，改进您的代码完全没有警告）。

另一答案

通常我调试分段错误的第一步是：

1. 使用调试符号（-g选项）编译应用程序，但保留优化选项以避免更改
2. 使用gdb在gdb --args ./myprog下运行程序，然后在命令提示符下运行r

如果你很幸运并且程序崩溃了，那么输入bt（backtrace）来查看它崩溃的函数，从哪个函数调用，直到main（或者线程启动）。

如果可能的话，更好的选择是在valgrind下运行可执行文件，以查看它首先检测到的“坏”行为是什么。在许多情况下，在数组边界之外执行读取或写入等不良操作不会立即生成段错误，valgrid将向您显示您无法访问的位置上的第一个读取或写入操作（但可以“工作”当程序正常执行时静默）。使用valgrind的缺点是执行非常慢，因为程序基本上使用模拟处理器运行;它太慢了，可能无法在预期的上下文中运行程序（例如，因为它需要与将超时的设备进行通信）。

另一个选择是使用地址清理程序（-fsanitize=address）编译程序。这将在可执行文件本身中添加代码，以检查边界外的内存访问或释放内存。优点是执行虽然比常规的非检测可执行文件慢，但比在valgrind下运行程序要快得多。

另一答案

如果核心转储不可用，GDB可以选择使用.exe文件进行调试。

target exec -- Use an executable file as a target

以这种方式使用它：

(gdb) target exec a.exe