tags:

views:

96

answers:

5

I have a core file I am examining. And I am just stumped at what can be the possible causes for this. Here is the behavoir:

extern sampleclas* someobj;
void func()
{
    someobj->MemFuncCall("This is a sample str");
}

My crash is inside MemFuncCall. But when I examine core file, someobj has an address, say abc(this address is properly initialized and not corrupted) , which is different from this pointer in the function stacktrace: sampleclass::MemFuncCall(this=xyz, "This is a sample str")

I was assuming that this pointer will always be the same as address for someobj i.e. abc should always be equal to xyz. What are the possible cases where these 2 addresses can be different??? Fyi, This app is single threaded.

+2  A: 

Ship optimizations can make things appear very strange in a debugger. Recompile in debug mode (optimizations off), and repo.

Another possible explaination is if the calling convention (or definition in general) is wrong for MemFuncCall (there is a disagreement between the header you compiled with and when MemFuncCall was compiled). You have to try hard to get this wrong, though.

Terry Mahaffey
So when optimization is on, *this will be a different object?? problem is I can't repo it nor the client.
VNarasimhaM
Most likely. Particularly so as C++ calling conventions typically use a register to pass `this` (e.g. `ECX` for VC++ `__thiscall`), which is of course promptly overwritten in the body of the method as soon as it's not used anymore.
Pavel Minaev
@VNarasimhaM: no, it won't be a different object. It just may be that, at this point, the memory location or register that was used to store the `this` pointer in the method being called was no longer used, and was overwritten by some other value that needed to be stored.
Pavel Minaev
@VNarasimhaM, if you don't have a repo, then consider this an excellent chance to practice your ship debugging skills. As I said in my answer, the debugger can just be wrong about the values of some variables in ship mode: you have to figure out what the "real" value is (which it looks like you've already done), and just ignore the debugger inconsistency as a red herring and move on with your investigation.
Terry Mahaffey
A: 

One thing I can think of is a corruption of vtable.

Kugel
+1  A: 

It is possible. Maybe some kind of buffer overrun? Maybe the calling convention (or definition in general) is wrong for MemFuncCall (there is a mismatch between the header you compiled with and when MemFuncCall was compiled).

Hard to say. But since this is single threaded I would try following technique. Usually memory layout in apps is the same between reruns of application. So start your application under debugger, stop it immediately and put two memory breakpoints on addresses 0xabc and 0xxyz. You have good chance of hitting breakpoints once someone is modifying this memory. Maybe than stack traces will help?

Michal Sznajder
Found the problem and it was because of buffer overrun.
VNarasimhaM
+1  A: 

In the case of multiple inheritance the this pointer can be different from the pointer to the "real" object:

struct A {
  int a;
  void fa() {  std::cout << "A::this=" << this << std::endl;  }
};

struct B {
  int b;
  void fb() {  std::cout << "B::this=" << this << std::endl;  }
};

struct C : A, B {
};

int main() {
   C obj;
   obj.fa();
   obj.fb();
}

Here inside obj.fa(), this will point to the A part of obj while inside fb() it will point to the B part. So the this pointers can be different in different methods, and also different from &obj.

As a reason for the crash a possibility would be that someobj was deleted before and the pointer is no longer valid.

sth
I doubt if someobj was deleted. When I do *someobj, everything looks correct. But inside the function if I do *this everything is wrong.
VNarasimhaM
+1  A: 

since the pointer someobj is defined externally it could the that there is some inconsistencies between your compilation units. try to clean everything and rebuild the project

Alon