Deleting an object which was created in a DLL

Question

I need some clarification regarding runtime/heap issues when deleting an object which was created in a DLL. It needs some introduction before I come to my questions...

In my project a DLL (which is specified by its name) returns a new Grabber object. In an earlier version of my code, the DLL exported a function like this:

extern "C"
__declspec(dllexport) Grabber* CreateGrabber(string settings)
{
    return new SomeSpecificGrabber(settings);
}

In the EXE I used a static function like this to create a new Grabber object:

static Grabber* createGrabberObject(const std::string& grabberType, const std::string& grabberSettings)
{
    FARPROC hProc = 0;

    // load dll with the name of grabberType
    HMODULE hDLL = LoadLibrary(grabberType.c_str());

    // get address for CreateGrabber function
    hProc = GetProcAddress(hDLL, "CreateGrabber");

    // instantiate a function pointer of our type and typecast the address
    // of the CreateGrabber function to this type
    CreateGrabberFunctionType CreateGrabberFunction = (CreateGrabberFunctionType)hProc;

    // call CreateGrabber in DLL to get a Grabber object
    return CreateGrabberFunction(grabberSettings);
}

In the EXE the lifetime of a Grabber object is managed by a smart pointer:

shared_ptr<Grabber> myGrabberObj = shared_ptr<Grabber>(createGrabberObject("SomeGrabber.DLL", "Settings"));

This all worked fine as long as I compiled the EXE and the DLL with the /MDd setting (VC++ 2010), which means that EXE and DLL used the same heap.

Now I want to compile my solution with the /MTd setting. With this I got a runtime assert of type _CrtIsValidHeapPointer for the settings string object I passed to the DLL. This makes sense because the DLL tries to delete a string object which was created in the EXE. And they don't use the same heap anymore.

I got around this problem by changing the exported DLL function a little bit (const char* instead of string):

extern "C"
__declspec(dllexport) Grabber* CreateGrabber(const char* settings)
{
    return new SomeSpecificGrabber(settings);
}

And in createGrabberObject I pass grabberSettings.c_str() instead of grabberSettings to the DLL function.

Now everything works fine again. But now comes my first question: Why don't I get the _CrtIsValidHeapPointer assertion when myGrabberObj is deleted? The object was created from within the DLL but is deleted from within the EXE (by the smart pointer). Why don't I have the same problem here as with the string object above?

I guess a clean solution would be that the DLL also exports a function like this:

extern "C"
__declspec(dllexport) void DeleteGrabber(Grabber* grabber)
{
    delete grabber;
}

Then I would also have a static function in my EXE which calls DeleteGrabber in a DLL:

static void deleteGrabberObject(const std::string& grabberType, Grabber* grabber)
{
    FARPROC hProc = 0;

    // load dll with the name of grabberType
    HMODULE hDLL = LoadLibrary(grabberType.c_str());

    // get address for DeleteGrabber function
    hProc = GetProcAddress(hDLL, "DeleteGrabber");

    // instantiate a function pointer of our type and typecast the address
    // of the DeleteGrabber function to this type
    DeleteGrabberFunctionType DeleteGrabberFunction = (DeleteGrabberFunctionType)hProc;

    // call DeleteGrabber in DLL
    DeleteGrabberFunction(grabber);
}

This static function could then automatically be called by the smart pointer:

shared_ptr<Grabber> myGrabberObj = shared_ptr<Grabber>(createGrabberObject("SomeGrabber.DLL", "Settings"), 
boost::bind(deleteGrabberObject, "SomeGrabber.DLL", _1));

This also works. But here comes my second question: The static functions createGrabberObject and deleteGrabberObject both load the DLL. Does it mean that two different heaps are created because two instances of the DLL are loaded (then this solution would not solve my problem at all)? Or do these two static functions use the same heap?

I hope someone can explain what's going on here...

Answer 1

The DLL is reference counted, not loaded twice, and when you use LoadLibrary then it's only loaded once anyway and they will use the same heap. The static function is the normal solution to this problem.

Answer 2

For your second question, just because you load the DLL twice doesn't mean there are two instances. The OS is smart enough to only load it once.

EDIT: For the first question, it's probably because either the shared pointer never actually goes out of scope OR because the VC runtime isn't able to detect the case properly (it didn't fatally fail but the memory wasn't freed).