Re: Heap problems after FreeLibrary
Hi, thanks for your answers.
The code for the class ("SomeObject") resides in a statically linked
Library that is linked by both the EXE and the DLL so I assumed that
the code souldn't get unloaded.
However, I indeed verified that it seems to work when the class only
has a trivial destructor, so your explanation makes sense.
Any suggestions what's the best way to resolve this (I'm working with a
rather large codebase and I would like to make as little changes as
possible).
A little more info: We have this large library. The EXE statically
links against that library. The DLL I am talking about is part of a
plugin mechanism within the library - basically, it is supposed to
allocate some objects (most are simple like Matrix and Vector, but some
also have virtual functions, class members, etc.) and then gets
unloaded.
--
Thanks for your help,
Stefan
Carl Daniel [VC++ MVP] schrieb:
"Stefan" <punkman@uboot.com> wrote in message
news:1147724910.793805.61170@y43g2000cwc.googlegroups.com...
Ok, here's a clarification:
--
EXE code:
SomeSharedDataStucture *pData = new SomeSharedDataStucture;
HINSTANCE hLibrary = LoadLibrary("mylib.dll");
SomeAPIFunctionType someAPIFunction = (SomeAPIFunctionType)
GetProcAddress(hLibrary,"someAPIFunction");
someAPIFunction(pData);
FreeLibrary(hLibrary);
delete pData->pObject; // <- fails, but works if FreeLibrary is
commented out
--
DLL code:
extern "C" __declspec(dllexport) void
someAPIFunction(SomeSharedDataStructure *pData)
{
pData->pObject = new SomeObject();
}
Where's the code for SomeObject? If it's in the DLL, then you're unloading
the code for the destructor and then attempting to call it. It makes no
difference how (or even if) the class is linked with MFC or the CRT. Unless
the class has a trivial destructor (no virtual functions, no members of
class type), then code IS generated for a destructor whether you wrote a
destructor explicitly or not.
-cd