• Advertisement

Archived

This topic is now archived and is closed to further replies.

DLL questions

This topic is 5488 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just futzing around with DLLs a bit after I got them working. The biggest thing that I haven''t seen mentioned in many places is being careful about memory. I thought they get mapped onto the loading process'' memory space but it seems like they don''t, e.g. if I return an object by value, when I destruct it I get an error in RtlHeapIsValid or a similar CRT routine. Is there any way around this? It is a pain in the rear. Another instance where it sucks is the instantiation routine to get at the derived class has to have a double pointer. Secondly I enable CRT memory allocation tracking in the main executable, but it doesn''t see memory leaks in DLLs. This is most likely related to the above, but I end up having to duplicate some code. These are plugin DLLs loaded at runtime if it helps.

Share this post


Link to post
Share on other sites
Advertisement
The version of the C runtime library used by the DLL ****MUST**** be exactly same as the version of the C runtime library used by the application which uses the DLL if you intend passing C runtime library objects (file handles, memory pointers etc) between the two.

If you for example allocate memory in the DLL and then free that memory in the application using the DLL and the version of the CRT is different in any way then you will get exactly the issues you describe.

Even mixing debug and release versions of the same CRT version will cause those issues, for example the DLL using "Debug Multithreaded DLL" and the client application using the "Release Multithreaded DLL" will cause those kinds of issues.

The usual and safest solution is to put "release" style functions inside the DLL so that memory allocated inside the DLL is free''d inside the DLL.

In summary:
1) DON''T mix CRT versions
2) Fix the problem in your DESIGN

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
I''m using DLLs as plugins too, but i never return a dll-object to the application by value, ireturn a pointer,
very simple Example:
//main app code
"a base class"
class Object
{
....
};

//inside de dll
class ObjectBublic Object A
{
.....
};
to get that object i use something like this
(Method A)
Object * GetObject()
{
return new ObjectB;
}
Or... something like this
(Method B)
void GetObject(Object **obj)
{
*obj=new ObjectB;
}

And in the main app

Object *plugin=0;
..
get a pointer to the "GetObject" proc
..

(Method A)
plugin=GetObject();
(Method B)
GetObject(&plugin);
...some error handling

...On exit

delete plugin;

..free the library

and when i want to destroy it i yust call a normal "delete" on the object retrieved. To avoid memory leaks you must delete the pointer (instance) before unloading the DLL.

Share this post


Link to post
Share on other sites
I''d recommend using a custom smart pointer. When the reference count hits 0 automatically call the DLL''s Release(). This stops the user application from being able to do "delete object" and bring down the house.

Joanus D''Mentia

Share this post


Link to post
Share on other sites
Thanks for the posts. I switched the CRT to use the multithreaded debug DLL in all the projects and now it shares gracefully, along with making super small EXE sizes. I think I''m in love here

Share this post


Link to post
Share on other sites

  • Advertisement