If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

problem with freeing memory in dll

i have a dll that exports a class - it uses an abstract base class with pure virtual functions(defined in a header file), then a function to export it that returns a new object. insided the class is a 'release' function that deletes the object. now in another dll of mine, i dont do anything with the deconstructor, but in this one for some reason i have to have the same 'delete this' as i do in the release function or it crashes. now in the host application is where i get some sort of problem. note - it runs/finishes without error but some code isnt being exectued or something.

Re: problem with freeing memory in dll

for the 1st reply: honestly i dont know why i needed it, i saw it done that way in a tutorial i read when learning how to export a class. and also the program crashes if i dont... 2nd reply - the release function is a class member in the class that's exported by CreateObject so you dont need to call getprocaddress for that. and i did check and it is getting fired correctly. here is a more complete code:
//#### header file for the dll
#if defined(DLL_EXPORT)
#define MYAPI __declspec(dllexport)
#else
#define MYAPI __declspec(dllimport)
#endif
class IMyObj //abstract interface
{
public:
//note - in sample tutorials ive read it says to have a deconstructor for the
// interface class but whenever i add 'virtual ~IMyObj()=0;' it doesnt compile.
virtual bool function1()=0;
virtual bool function2()=0;
virtual void release()=0;
};

Re: problem with freeing memory in dll

sorry bout the tags guys. i totally agree that deleting it twice should cause an error. but when i remove one i get another crash. For the compilor I'm using Borland 5.5 command line tools (bcc32). the error -
(in ollydbg) - access violation when writing to -

Re: problem with freeing memory in dll

Originally Posted by rhboarder

here you go, i've attached a zip file containing the source files. thank you for taking a look at it.

The design is bad.

You are using two different heap managers, the DLL's and the apps. You can't call "new" in the DLL, and then use that same pointer in the call to "delete" in the application. The bottom line is -- unless your application and DLL are using the same heap manager, pointers returned by "new" from one DLL/app are incompatible with calls to "delete" in another DLL/app.

The DLL should be solely responsible for allocating and deallocating its own memory. If the DLL allocates, the DLL does the deallocation. The app shouldn't be in the business of knowing how the instance was created -- that detail is within the DLL.

Re: problem with freeing memory in dll

Sorry that took me a while. Haven't used Borland in a while, so I needed to crank up my old pc. For your reference I'm using Borland C++ explorer 2005.

The code you attached was fine, I took out the two lines mentioned by Paul and Zaccheus and and there was little else wrong with it as such. That's not to say it didn't crash, just I don't think you'd done anything else particularly wrong.

The reason why putting "delete this;" in the destructor stopped it crashing was because (somehow) the resulting stack overflow it was causing was making it crash silently before it had chance for anything else to go wrong. And the line "delete spy" was doing nothing for me at all (different compiler version perhaps ).

So What's making it crash?
A little testing revealed that calling any virtual function in the DLL would cause a crash iif FreeLibrary was used to unload the dll. The crash actually occurred at the very end of your program (when main() called return 0; ). My only explanation is that its being caused by a little black magic going on in the way Borland calls virtual functions.

How to fix it?
you need to stop using vartual function calls across exe/dll boundaries or stop using Borland. When I compiled this with MinGW everything ran fine, when I removed all calls to virtual functions in the DLL in Borland it ran fine. When I had only one call to a virtual function that did nothing more than [ cout << "hello world" << endl; ] it crashed again.

Accessing DLLs in this way is really only necessary to load plug-in modules or to load a DLL after the program has started running. I was just wondering if you've been told to load a DLL this way by an article / tutorial of if you have a specific reason for doing it this way?

Re: problem with freeing memory in dll

yes it was from several articles i had read that made me think you had to do it that way. with the virtual functions, doesn't it have to be that way though because you change the implementation in the derived class? i've removed the virtual keywords. but now i get an error when compiling the application that loads the dll:

Re: problem with freeing memory in dll

Keep the source in a folder and just add it every project
The easiest option, but it does increses build time and isn't the best way to share a library that's not open source.

Staticly compile it into a lib and add it to every project
It should be no more dificult than using a DLL. You get a single exe at the end. But you can't mix and match libraries without re-compiling your exe (unlike dlls)

Compile it into a dll
When you compile a dll, Borland will give you a lib as well. This contains stubs for all your functions. Each "stub" simply calls the aprorpriate function in the dll.

I want to use a dll... but how?
There are two options:

By compiling the asociated lib into your exe (making it appear as if everything in the dll is in the lib). With this option windows will load the dll at the same time it loads your exe do all the work in connecting the two for you.

By loading the dll after the program has started running using "LoadLibrary". This is only useful when you want to load a dll after the program has started running, or when you want to make your program load different dlls based on settings or a script.

If you're just starting out with dlls, I'd get to grips with option 1 first.

Do I need virtual functions?
No, not unless you'd need them anyway to achieve your goal in a standalone exe.
You can even replace virtual functions with function pointers in the object if virtual functions are going to cause problems.

Why do dlls get used?

They're a reasonably reliable way to make redistributable code without giving out the source code.

Advanced users can use them as a way to interface between code built with a number of different compilers.

You can mix and match dlls after the exe has been compiled (as long as they have the same functions).

You can make a program that accepts plugins.

because they're cool!

Okay commercially they dont get used because they're cool, but particularly when learning to program it's allways fun to see what they're about.