如何在 gdb 中调试这个 SIGSEGV？答案

【问题标题】：How can I go about debugging this SIGSEV in gdb?如何在 gdb 中调试这个 SIGSEGV？
【发布时间】：2026-01-19 13:25:01
【问题描述】：

我正在构建以前工作的代码，但我遇到了一个段错误，我不知道出了什么问题。 gdb 捕捉到错误，但它没有指出明显的原因。它显示的源代码行是一个函数名称，因此它甚至没有进入函数。如果我查看指令的反汇编，它仍在设置堆栈，所以堆栈可能被搞砸了。那么我应该如何调试呢？这是在 QNX 6.2 中，仅限控制台 gdb。

0x0816b829 in __ml (this=0x79b963c, anMultiplier=0) at ../u_matrix.cpp:56
56      tcMatrix tcMatrix::operator*(float64 anMultiplier)

0x816b820 <__ml>:       push   %ebp
0x816b821 <__ml+1>:     mov    %esp,%ebp
0x816b823 <__ml+3>:     sub    $0x13ac,%esp
0x816b829 <__ml+9>:     push   %edi
0x816b82a <__ml+10>:    push   %esi
0x816b82b <__ml+11>:    push   %ebx

【问题讨论】：

标签： gdb qnx

【解决方案1】：

您崩溃的指令是push %edi。

这很可能意味着您有堆栈溢出。

堆栈溢出的一个可能原因是无限递归。如果(gdb) where 显示出无穷无尽的函数调用流，那就是你的问题。

如果where 显示合理的调用顺序，则重复执行info frame 和up，寻找尺寸过大的帧。

最后，问题可能是由执行环境的变化引起的，而不是由程序中的任何内容引起的。我不确定ulimit -s 的 QNX 等效项是什么，但您的堆栈限制可能太小了。

【讨论】：

【解决方案2】：

按照受雇俄罗斯人的回答：

ulimit -s 适用于 QNX，但默认情况下是无限制的。

我会尝试

ldrel -S2M -L 你的可执行文件名

调整初始堆栈分配/惰性以查看 coredumps 是否再次发生。您还可以使用 QCC 的 -N 标志将初始堆栈大小设置得更高。

【讨论】：

【解决方案3】：

如果在 gdb 中执行“bt”有什么相关的吗？

【讨论】：

【解决方案4】：

“this”指针看起来很乱 - 0x79b963c 似乎已关闭，但这可能取决于对象的初始化方式。试试

打印 *this

看看数据是有意义的还是垃圾。看起来您的源代码与可执行文件不匹配 - 您在示例中的行看起来像运算符覆盖声明而不是可执行文件。

我会忽略特定的行，在源代码中查找整个 _ml 函数并尝试打印一些局部变量，看看您是否在循环或其他包含它们的范围内。

我猜你有一个矩阵乘法运算符，其中一个矩阵乘以一个浮点数 - 很可能这类似于索引超出范围，在内存范围之外运行的某种问题损坏了堆栈。

就像 Unknown 说的那样，也试试 bt - 如果它返回了很多 ??()，那么你确实有一个损坏的堆栈。

【讨论】：

【解决方案5】：

QNX 现在似乎支持valgrind（至少从 6.5 开始）：

http://community.qnx.com/sf/frs/do/viewRelease/projects.valgrind/frs.valgrind.valgrind_3_10

【讨论】：

其他回复也不一定跟在问题后面（在 gdb 中），+1 以反对投票。

【解决方案6】：

你也可以尝试 valgrind'ing 它，它可以提供更多信息。

【讨论】：

Valgrind 什么时候支持 QNX？
哎呀，我的错误，对此感到抱歉