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.
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?
It's possible that an optimization in the code is confusing the debugger. This is a common issue when debugging retail code. Try disabling optimizations, re-running the scenario and see if you get the same problem.
this pointer is local to frame.
Is the other frame belongs to 'C' function, you could see smth like 0x200
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 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.
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.