Derived class vtable corrupted?

Need help in root causing a vtable corruption issue(not sure if that’s what is happening). Here is the very simplified version of the code.

class CBase
{
public:
    CBase()
    virtual ~CBase()
    virtual void base_virtual_fn1() = 0;
    virtual void开发者_运维技巧 base_virtual_fn2();
private:
    CData   _data;
};

class CDerived : public CBase
{
public:
    CDerived();
    virtual ~CDerived()
    virtual void base_virtual_fn1();
    virtual void base_virtual_fn2();
    virtual void derived_virtual_fn1();
    virtual void derived_virtual_fn2();
private:
    // Contains vectors , maps, integers, bools. 
};

When I create an instance of CDerived and call the derived class virtual function say derived_virtual_fn2 the other function gets called i.e. derived_virtual_fn1.

Calls to base_virtual_fnx has no issues.

This only happens with object created on the heap and not for local object.

These classes are in a shared library. I’m using gcc 3.4.2 on Linux (SLES 10). There is no pragma pack directive in any of this code and there is a mix of C and C++ code (extern c is used). What could be the issue here?

I forgot to mention that there are there is tons of other code (executable, libraries)

---

Here is a nasty mistake I made that took me forever to find. The compiler/debugger/valgrind gave me no insight into what was going on. There should be someway to debug these kinds of errors:

The base class was compiled in a library with "SOME_PACKAGE" defined:

class interface {
    virtual int function1(int);
#ifdef SOME_PACKAGE
    virtual int function2(int);
#endif
    virtual int function3(int);
}

class base : public interface {
    int function1(int);
    int function2(int);
    int function3(int);
}

The derived class was compiled later without SOME_PACKAGE defined

class derived : public base {
    int function1(int);
    int function3(int);
}

calls to function3 caused jumps to function2 which I was eventually able to figure out with the debugger, but it took me a long time to find the cause.

---

If it only happens for objects created on the heap, the most likely explanation is heap corruption, which possibly has nothing to do with the two classes you mention. Check your allocations/deallocations! check that you're correctly using delete [] to delete arrays, etc. Maybe use valgrind or similar as well.

---

Sorry for necromancing this thread, but when debugging a similar problem, I finally found a possible answer that is not yet listed here, and I believe it will be beneficial for other people stumbling across this kind of problem.

The answer (in my case) is, that there were still parts of the code installed, our build system, however, was not able to ensure that the tests would actually link against the freshly and correctly compiled versions. Instead, dynamic libraries were loaded which expected a different vtable layout than the code that called them.

Of course, possible symptoms are that wrong functions get executed, or that the very call to a virtual function fails with a segmentation fault. It really depends on how the vtable layout changed between the two versions.

If this is the reason behind your problem, make uninstall should fix it.

---

There's nothing shocking in the almost nothing you show us ;-)

When I happen to understand nothing about the memory corruption, I'm used to turning the utility gflags on. It is pretty sensible a little application and detect many criminal things, far before they provoke unlogical nightmares. However it makes things turns really slow.

Try understanding most of the steps where gflags screams.

---

This is almost always stale objects. Make clean or attempt to locate stale object files in your linker path.