Segfault when calling a virtual function in another DLL

I have a two-part program where the main core needs to have an adapter registered and then call back into the register. The parts are in separate DLLs, and the core doesn't know the adapter's specifics (besides methods and parameters ahead of time). I've tried setting it up with the following code and recieve a segfault every time the core tries to call an adapter method:

Core.hpp/cpp (combined and simplified):

class Core
{
public:
    Core()
        : mAdapter(NULL)
    { }

 开发者_运维知识库   void DoStuff(int param)
    {
        if ( this->mAdapter )
        {
            this->mAdapter->Prepare(param);
        }
    }

    void Register(Adapter * adapter)
    {
        this->mAdapter = adapter;
    }

private:
    Adapter * mAdapter;
};

Adapter.hpp/cpp (in the core library):

class Adapter
{
public:
    Adapter(Core * core) { }

    virtual void Prepare(int param)
    {
        // For testing, this is defined here
        throw("Non-overridden adapter function called.");
    }
};

AdapterSpecific.hpp/cpp (second library):

class Adapter_Specific
    : Adapter
{
public:
    Adapter_Specific(Core * core)
    {
        core->Register(this);
    }

    void Prepare(int param) { ... }
};

All classes and methods are marked as DLL export while building the first module (core) and the core is marked as export, the adapter as import while building the adapter.

The code runs fine up until the point where Core::DoStuff is called. From walking through the assembly, it appears that it resolves the function from the vftable, but the address it ends up with is an 0x0013nnnn, and my modules are in the 0x0084nnnn and above range. Visual Studio's source debugger and the intellisense shows the the entries in the vftable are the same and the appropriate one does go to a very low address (one also goes to 0xF-something, which seems equally odd).

Edit for clarity: Execution never re-enters the adapter_specific class or module. The supposed address for the call is invalid and execution gets lost there, resulting in the segfault. It's not an issue with any code in the adapter class, which is why I left that out.

I've rebuilt both libraries more than once, in debug mode. This is pure C++, nothing fancy. I'm not sure why it won't work, but I need to call back into the other class and would rather avoid using a struct of function ptrs.

Is there a way to use neat callbacks like this between modules or is it somehow impossible?

You said all your methods are declared DLL exports. Methods (member functions) do not have to be marked that way ,exporting the class is sufficient. I don't know if it's harmfull if you do.

1. You are using a lot of pointers. Where are their lifetimes managed?
2. Adapter_Specific is inheriting private from Adapter in your example
3. Adapter has a virtual method so probably needs a virtual destructor too
4. Adapter also has no default constructor so the constructor of Adapter_Specific won't compile. You might want it to construct the base class with the same parameter. This does not happen automatically. However see point 6.
5. Constructors that take exactly one parameter (other than the copy constructor) should normally be declared explicit.
6. The base class Adapter takes a parameter it does not use.

The problem ended up being a stupid mistake on my part.

In another function in the code, I was accidentally feeding a function a Core * instead of the Adapter * and didn't catch it in my read-through. Somehow the compiler didn't catch it either (it should have failed, but no implicit cast warning was given, possibly because it was a reference-counted point).

That tried to turn the Core * into an Adapter and get the vftable from that mutant object, which failed miserably and resulted in a segfault. I fixed it to be the proper type and all works fine now.

__declspec(dllexport) on classes and class members is a really bad idea. It's much better to use an interface (base class containing only virtual functions, it's essentially the same as the "struct of function pointers" you didn't want, except the compiler handles all the details), and use __declspec(dllexport) only for global functions such as factory functions. Especially don't call constructors and destructors directly across DLL boundaries because you'll get mismatched allocators, expose an ordinary function which wraps the special functions.