2

我正在构建以前工作的代码，但我遇到了段错误，我无法弄清楚出了什么问题。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
4

6 回答 6

4

您正在崩溃的指令是push %edi.

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

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

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

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

于 2010-07-24T03:32:22.120 回答
3

遵循受雇俄罗斯人的回答：

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

我会尝试

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

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

于 2010-07-24T15:50:38.353 回答
1

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

于 2010-07-23T14:19:17.840 回答
1

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

打印 *this

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

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

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

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

于 2010-07-23T17:09:47.543 回答
1

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

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

于 2015-08-25T10:41:57.730 回答
-1

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

于 2010-07-23T14:20:15.593 回答