1. 首页
  2. 问答
  3. 我怎样才能在gdb中调试这个SIGSEV？

我怎样才能在gdb中调试这个SIGSEV？

2010-07-23 82 views
2

我正在构建以前的工作代码，但我得到一个seg故障，我无法弄清楚出了什么问题。 gdb捕获错误，但它并没有指出一个明显的原因。它显示的源代码行是一个函数名，所以它甚至没有进入函数。如果我看看指令的解构，它仍然在设置堆栈，所以堆栈可能会混乱。那么我应该如何去调试呢？这是在QNX 6.2中，仅用于控制台gdb。我怎样才能在gdb中调试这个SIGSEV？

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

来源

2010-07-23 CptanPanic

回答

4

你正在崩溃的指令是push %edi。

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

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

如果where显示合理的通话顺序，重复执行info frame和up，查找具有不合理大尺寸的帧。

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

来源

2010-07-24 03:32:22

1

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

来源

2010-07-23 14:19:17 Unknown

-1

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

来源

2010-07-23 14:20:15 Zev

+0

因为确实在Valgrind的支持QNX？ – 2010-07-24 03:33:33

+0

哎呦，我的错误，对此感到抱歉 – Zev 2010-08-12 19:12:50

1

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

print * this

并查看数据是否有意义或是垃圾。它也看起来像你的源不匹配的可执行文件 - 你在示例中的行看起来像一个运算符覆盖声明，而不是可执行文件。

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

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

像Unknown说的，尝试bt以及 - 如果它回来了很多??（）的，那么你确实有一个腐败的堆栈。

来源

2010-07-23 17:09:47 m1tk4

2

继俄罗斯就业的回答：

的ulimit -s QNX的作品，但它是默认无限。

我将实验

ldrel -S2M -L yourexecutablename

调节初始的堆栈分配/懒惰，看是否核心转储再次发生。您还可以使用QCC的-N标志将初始堆栈大小设置得更高。

来源

2010-07-24 15:50:38 m1tk4

相关问题

 相关问题