问题描述
我正在检查一个核心转储，并注意到在一个帧'this'指针不同于下一帧（在同一个线程）。不只是有点不同，它从0x8167428到0x200。
I am examining a core dump, and noticed that in one frame the 'this' pointer is different than in the next frame (in the same thread). Not just a little different, it went from 0x8167428 to 0x200.
我不是那么精通使用GDB，但这似乎不对我。
I am not that well-versed in using GDB, but this does not seem right to me. Is this problematic, and if so, what could be the cause?
推荐答案
this 指针可以在gdb跟踪中的帧之间改变，如果下一帧中的函数在不同的对象上调用（即使对象是相同类型），因为这是针对特定实例。这可能不是您的问题。
The this pointer can change between frames in a gdb trace if the function in the next frame is called on a different object (even if the objects are the same type), since this is for the specific instance. This is probably not your problem.
0x200 code> this ，几乎肯定表示某种类型的内存损坏。 this 指针有时存储在堆栈中，并作为不可见的第一个参数传递给函数。因此，如果你已经破坏了堆栈（通过走出边界写入另一个变量），你可以看到这个指针已损坏。
0x200 is not a valid value for this, and almost certainly indicates memory corruption of some type. The this pointer is sometimes stored on the stack and passed as an invisible first argument to a function. So if you have corrupted the stack (by going out of bounds writing to another variable) you could see the this pointer corrupted.
值 0x200 本身很有趣。因为它非常接近 0 ，但实际上不是 0 ，它表示您正在查看的实例是可能是另一个对象或数组的一部分，位于该对象/数组开头的 0x200 字节，对象/数组的地址实际上是 NULL 。看看你的代码你应该能够很容易地弄清楚哪个对象被设置为 NULL ，这导致报告 0x200 。
The value 0x200 itself is interesting. Because it is so close to 0, but not actually 0, it indicates that the instance you're looking at is probably part of another object or array, located 0x200 bytes from the beginning of that object/array, and that the object/array's address is actually NULL. Looking at your code you should be able to pretty easily figure out which object has gotten set to NULL, which is causing this to report 0x200.
这篇关于“这个”指针在GDB回溯跟踪中的变化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！