我见过this帖子。我的情况略有不同,我正在努力弄清楚"this"
指针是如何被破坏的。
我正在使用Qt 4.6.2框架,使用他们的QTreeView
和我自己的模型。我得到的回溯(86帧长,有很多递归,这就是为什么我没有粘贴整个东西,它在这个pastebin只涉及他们的代码。
它终于在QBasicAtomicInt :: deref中对某些汇编程序进行了段错误,但很明显它已经进一步衰落,这三个框架证明了这一点:
#15 0x01420fd3 in QFrame::event (this=0x942bba0, e=0xbf8eb624) at widgets/qframe.cpp:557
#16 0x014bb382 in QAbstractScrollArea::viewportEvent (this=0x4, e=0x93f9240) at widgets/qabstractscrollarea.cpp:1036
#17 0x0156fbd7 in QAbstractItemView::viewportEvent (this=0x942bba0, event=0xbf8eb624) at itemviews/qabstractitemview.cpp:1610
在第17帧中,this
为0x942bb0
。在第16帧中,this
应该是相同的,就像在第17帧中它调用它的祖先对同一方法的实现一样。但是this
变为0x4。
有趣的是在第15帧(同样,第16帧已经调用了它的祖先对同一函数的实现),'this'指针被恢复为0x942bba0
。
如果您查看完整回溯的pastebin,您可能会看到一些“值优化输出”。我已经使用优化编译了应用程序;我现在已经将gcc设置为-g3 -O0
,所以下次我可能会有更多的东西。但是当然现在我不能让它崩溃 - 这是一个相当困难的错误(尽管如此仍然非常重要)所以我不认为这太可疑了。
鉴于优化,this
pointer=0x4
是否异常或绝对错误?奇怪的是,这些viewportEvent框架中没有真正的代码 - 它们只是对事件的类型进行切换,它通过switch语句,并返回其祖先的实现。
Valgrind似乎没有抛出任何问题,虽然我还没有让它在Valgrind中崩溃。
之前有人见过这种行为吗?可能导致什么呢?
答案 0 :(得分:8)
在调试优化版本之前,我已经看到过这种情况,而且它从来没有表明真正的错误对我来说是什么。
首先考虑局部变量更容易。在非优化构建中,所有内容都在内存中具有指定位置,并且必须在每行代码之后存储。这是调试器可以找到的。在优化的构建中,值可以存储在寄存器中而无需写入存储器。这是优化构建的改进性能的主要部分。调试器不理解这一点,并且总是会查看内存,因此您经常会看到错误的值。
参数可能会发生同样的情况。如果优化器决定在寄存器中传递参数,则调试器仍将查看堆栈帧。更具体地说,在参数将根据调用约定的规则的位置。
堆栈的下一帧具有正确恢复的值这一事实表明生成的指令正确处理此参数,但调试器只是不知道在哪里查找它。