How to debug an erroneous call stack in Visual Studio

Question

I am working with a huge class from a 3rd-Pary library, here is an excerpt of relevant stuff:

class SomeClass {
    // ...
public:
    // ...
    virtual int SetTableSize(unsigned int uiTableID, int iSize);
    // ...
protected:
    // ...
    virtual int Set_0xB0_0x23_IsoTableData(unsigned char* ucData, int iLen);
    // ...
};

My application breaks with a memory access violation. The uppermost item in the call stack is a code line in the implementation of Set_0xB0_0x23_IsoTableData , the second item is a code line like this:

someClassInstance.SetTableSize(2, 400);

In debug view, ucData has the value 0x00000002 , so it really looks like instead of calling the implementation of SetTableSize , which should happen according to the code, Set_0xB0_0x23_IsoTableData gets called with the parameters specified - which obviously leads to an error, because the pointer isn't valid.

I have already spent much time figuring out what happens here. I compile the same code inside a different application with GCC on Linux, and it works there. Is this a Visual Studio compiler bug? I don't get any warning when I compile this code.

It's not possible to construct a minimal working example to reproduce the bug - at least not until I figure out the reason why this happens. The SomeClass header does have quite some #ifdef s in it, so the first thing I thought was that preprocessor defines were different when compiling the module containing SomeClass than when compiling my calling code. However, I double-checked and the definitions are the same.

So what I want to ask is basically:

• Under what conditions can a call to a virtual method invoke the implementation of another virtual method? (this is not about inheritance - the two methods are defined in the same class and do not even share their signature and have different visibility)
• How can I debug such an error? Is it possible to view the dispatch vector of the class instance in Visual Studio?

Answer 1

My standard answer for those kind of problems: Rebuild all. In some cases it is as simple / stupid as that (at least for Visual Studio).

If the error still remains, then what I'd do is debugging: Run the code as far as you can say "it cannot have happened by now". Then debug step by step, line by line and watch the call stack closely.

And no, this is not fun.