“this”指针在堆栈跟踪中损坏答案

【问题标题】："this" pointer getting corrupted in stack trace“this”指针在堆栈跟踪中损坏
【发布时间】：2011-08-30 06:14:14
【问题描述】：

我见过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，所以下次发生这种情况时，我可能会有更多的东西。但当然现在我不能让它崩溃——这是一个相当难以发生的错误（但修复非常重要）所以我认为这不太可疑。

考虑到优化，thispointer=0x4 是异常还是绝对错误？奇怪的是，这些 viewportEvent 框架中没有真正的代码——它们只是对事件的类型进行切换，它通过 switch 语句，并返回其祖先的实现。

Valgrind 似乎没有抛出任何问题，尽管我还没有让它在 Valgrind 中崩溃。

以前有人见过这种行为吗？可能是什么原因造成的？

【问题讨论】：

+1，很久以前我的代码也遇到过同样的问题；我不知道我是如何修复它的；但让我想起了旧时光。 :)
编译代码时有警告吗？先修复它们。
@iammilind：这是让这个问题成为最喜欢的问题的原因（通过点击星号），但不是为了投票。
@phresnel，投了赞成票，因为我很想知道答案。
this pointer=0x4 绝对是错误的。你永远不会在第一页得到东西。您现在需要的是一个可重现的测试用例——或者至少是一个核心转储。

标签： c++ qt4 this memory-corruption stack-corruption

【解决方案1】：

我之前在调试优化构建时看到过这种事情，但它从来没有表明真正的错误是什么。

首先考虑局部变量更容易。在未优化的构建中，所有内容在内存中都有其指定的位置，并且必须存储在每一行代码之后。这样调试器就可以找到它。在优化的构建中，值可以存在于寄存器中而无需写入内存。这是优化构建的改进性能的主要部分。调试器不理解这一点，会一直看内存，所以经常会看到错误的值。

同样的情况也可能发生在参数上。如果优化器决定在寄存器中传递参数，调试器仍然会查看堆栈帧。更具体地说，根据调用约定的规则，在参数所在的位置。

堆栈的下一帧正确恢复了值的事实表明生成的指令正在正确处理 this 参数，但调试器只是不知道在哪里查找它。

【讨论】：

对此的另一个变化是，即使参数是在堆栈上传递的，优化器也可能会在使用参数的位置完成后将内存位置重新用于其他用途。因此，回溯中的this pointer=0x4 可能是一条红鲱鱼 - 特别是如果this 指针参数正确显示在编号较低的帧中。
感谢您的回复。我现在禁用了优化，并且一直在努力让它再次崩溃——它发生在树视图上的拖放过程中，特别是当你释放手指压力时触摸屏发送有趣的位置时，所以不是这样易于自动化！一开始就很难复制。希望未优化的核心转储将显示一些更有用的结果。有趣的。所以理论上，如果我检查 coredump 中的汇编程序并查看寄存器，我可以弄清楚“this”应该是什么——但这可能没有帮助。