Dll allocations and crashes 2

[Nosferatu]

Does anybody had problems with crashes in DLL's because of memory allocations?

I have an exported class which is used in a project that invokes the DLL through an import library. When destroying the class, the program just crashes when deleting the class members (from within the class destructor, of course).

Any guidelines?
Thanks. [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[programsecrets]

Check the order of deallocation. If any objects are deallocated, but then referenced, it will cause a crash. For example, deallocating a parent object, then attempting to deallocate the child objects using the parent pointer will cause nasty results.

Also, this next part may sound simplistic, so I apologize. But be sure to check:

In the project that imports the library, as well as the class that is exported, *all* variables for allocated objects should be initialized to NULL values, then religiously checked for NULL:

1) immediately after allocation
2) before being initially used
3) before any and all deletions are attempted

Often "destructor" crashes are due to attempting to delete previously deleted objects.

I hope there's something here that actually helps you...

 

[Nosferatu]

Thanks... Actually, the first part sounded more simplistic, but only because of the context in which the DLL is built. I appreciate your reply and hope that you'll get back.

The thing is that this DLL was built with the code used in a Static Library, which performed perfectly, no problems at all.
But, as soon as I put the code into DLL, this particular destructor (maybe it's a generalized problem) started to cause havoc; therefore, I'm really puzzled about the DLL's usage of memory. I've seldom built DLL's, and the last DLL I've wrote was about 2 years ago.

Again, nothing like the things you describe in your post happens. It's clearly a sensitive matter which I'm not aware of and I hope I can get input from anyone of you out there (or... in here )...
[red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[RavenEris]

Are you using the STL? Microsoft DLLs don't like the STL, and any exported classes/members using it go bye-bye in a bad way during destruction. Static libraries are okay, but the whole dynamic-loading-linking thing goes nuts.

It has to do with the way processes share memory, the way templates need memory at run- and compile-time, and the way that Microsoft doesn't want to do STL right. ( =

 

[Nosferatu]

Thanks for the reply.
I am not using STL, but I am using my own template (only 1 template, I'm not extremely fond of working with them, even if it proved its usage in the static library version), which is really heavely used around the code - at least 20 classes use it. It is actually a double linked list template which holds only pointers and does deallocation of the objects as well in the destructor, as a convenience.

You might have a point and, if its 100% true, than I can go shoot myself in the foot cause there's no way that I change the whole code to root out the template I'm using.

However, I'll try to free the objects outside the template, popping one at a time and deleting them, maybe that will work.

[red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[didis]

Does this applies - allocate memory in the dll and deallocate from the host application? If so, might have a problem, since dlls with static link to runtime library create their own private heap. I faced this problem once; since I was in a COM environment, I could use the COM allocation functions.

 

[Nosferatu]

What do you mean by static link to applications? Using DLL's with import Libaries - therefore automatically loading the DLL's (static link?), as opposed to LoadLibary situation?
However, this is the situation as the DLL contains some string management classes which allocate memory (for example, for concatenating several strings).
Would you say then that if I am using LoadLibary the DLL will be loaded in the apps' memory space? [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro

 

[Urdle]

had the problem...
When I included the class' declaration in the DLL's cpp file, it was showing something like
---------
#include "class_B.hpp"
class C {
private:
B b;
B* pb;
int x;
public:
export C();
export ~C();
export foo();
}
--------
But I did not want the class B to appear in the programs that use the DLL...
for them, the class declaration was just
--------
class C {
private:
int x;
public:
import C();
import ~C();
import foo();
}
--------
That caused the compiler to allocate 4 bytes (=size of int) when instantiating, do absolutely strange things calling foo(); and crashing when deleting...
took a long time to find out the problem.

The best thing to do, seems to have a header looking like:
-----------
class C_Imp;
#ifdef EXPORT_C
#include "class_C_Imp.hpp"
#endif
class C
{
private:
C_Imp* c_imp;
public:
export_or_import C();
export_or_import ~C();
}
-------------
this way, the size for the pointer will be reserved and allocated by the constructor when an object of class C will be instantiated.
Another way to do this seems to use heritage, but I did not understood it yet.