VC Language - new/delete problem with DLLs (using multi-threaded DLL c-runtime)

Author

new/delete problem with DLLs (using multi-threaded DLL c-runtime)

2005-06-10, 4:03 pm

using VC6, SP5, i have the following problem:

i have a small boot loader that loads my primary DLL - let's call it A.dll.
further there is a class collection in X.dll which is linked via its libary to
all other DLLs using these classes (also to A.dll).
let's assume that there is a class X in X.dll
then i have several other DLLs (let's call them B.dll, C.dll, etc) which are
loaded explicitly via LoadLibrary(). these DLLs also depend on X.dll

so here's my problem:
if i call "new X" in A.dll and "delete X" in X.dll, then everything is fine.
if i call "new X" in B.dll and "delete X" in X.dll, then i get a crash on that
delete.

ofcourse i am using the multi-threaded DLL c-runtime library for all my DLLs.

my solution now is to have a create/destroy pair plus private
contructor/destructor for each class in X.dll so that memory is only allocated
and freed from inside X.dll which works, but i don't understand why this is
required.

any ideas on that?

thx,
Daniel

Doug Harrison [MVP]

2005-06-10, 4:03 pm

On Fri, 10 Jun 2005 15:08:51 GMT, daniel@nowhere.com wrote:

> using VC6, SP5, i have the following problem:
>
> i have a small boot loader that loads my primary DLL - let's call it A.dll.
> further there is a class collection in X.dll which is linked via its libary to
> all other DLLs using these classes (also to A.dll).
> let's assume that there is a class X in X.dll
> then i have several other DLLs (let's call them B.dll, C.dll, etc) which are
> loaded explicitly via LoadLibrary(). these DLLs also depend on X.dll
>
> so here's my problem:
> if i call "new X" in A.dll and "delete X" in X.dll, then everything is fine.
> if i call "new X" in B.dll and "delete X" in X.dll, then i get a crash on that
> delete.
>
> ofcourse i am using the multi-threaded DLL c-runtime library for all my DLLs.
>
> my solution now is to have a create/destroy pair plus private
> contructor/destructor for each class in X.dll so that memory is only allocated
> and freed from inside X.dll which works, but i don't understand why this is
> required.
>
> any ideas on that?

Are they all linking to the same CRT DLL?

Are they all compiled with the same options for things like struct packing?

Has B.dll been unloaded when X.dll deletes the object it created?

Do all objects fail in the same way for B.dll and X.dll?

--
Doug Harrison
Microsoft MVP - Visual C++

2005-06-11, 3:59 pm

>Are they all linking to the same CRT DLL?
yes

>Are they all compiled with the same options for things like struct packing?
yes

>Has B.dll been unloaded when X.dll deletes the object it created?
yes
could that be the problem?

>Do all objects fail in the same way for B.dll and X.dll?
i'm not exactly sure what you mean with this question.
i allocate one or two objects in B.dll or C.dll and they fail when they are
freed in X.dll.

thx,
Daniel

Doug Harrison [MVP]

2005-06-11, 3:59 pm

On Sat, 11 Jun 2005 15:12:50 GMT, daniel@nowhere.com wrote:

> yes
> could that be the problem?

If code in B.dll is used to destroy the object, yes. Sometimes this can
happen in non-obvious ways. For example, see:

http://groups-beta.google.com/group...eaf770212?hl=en

> i'm not exactly sure what you mean with this question.
> i allocate one or two objects in B.dll or C.dll and they fail when they are
> freed in X.dll.

I'm trying to determine the threshold for this failure. Does it occur with:

int
struct X1 {};
struct X2 { ~X2() {} };
struct X3 { virtual ~X3() {} };
struct MY_EXPORT X4 { ~X4(); };
struct MY_EXPORT X5 { virtual ~X5(); };

The macro MY_EXPORT is defined per this message:

http://groups-beta.google.com/group...818114037?hl=en

--
Doug Harrison
Microsoft MVP - Visual C++

Sponsored Links