Memory Management across DLLs
-
Hi guys, this is probably a very *niche* question, and I don't suppose I'll get many answers, but here's hoping ... :( My program has two components, let's call them ... program.exe and library.dll - library.dll is statically linked to program.exe throughout program.exe's entire lifetime. Suppose a function in program.exe calls a function in library.dll, which allocates some memory using the "new" operator. I've recently discovered that releasing this allocated memory from a function in program.exe causes a crash. You have to release the dynamic memory from the same *module* it was allocated in. Therefore, if I allocated memory using a statement in library.dll, I have to release it using another statement in library.dll, not in program.exe. It took me long enough to figure that out without any documentation, and that's fine, but my problem is as follows: Suppose I have a structure of two nested classes. class A; class B { A a; // contains an instance of A }; Class A is defined in library.dll, class B in program.exe Class B is instanced in the global scope in program.exe. Now, suppose I call a function in class B (program.exe) that then calls a function in class A (library.dll) to allocate some dynamic memory. Class A has a destructor that should theoretically release the memory once the lifetime of the instance "a" expires. When the program closes, this is usually done inside the exit() function when all destructors are executed, when the program is closing. But here comes my problem: Before the program closes, C++ throws an exception as the "delete" operator on the dynamic memory is executing. This happens, as I see it (and hopefully I'm wrong), because C++ somehow treats the "delete" statement that is defined inside library.dll as a code of program.exe because it's calling it from the global destructor. Having a destructor of class A in library.dll for the dynamic memory causes a crash. However, when I define a destructor of class B in program.exe that calls a function in class A to delete the memory, the program ends fine without any crashes. I hope I have made the matter clear, confusing though it may be. Does anyone have the slightest idea what may be going wrong? I'd be very grateful, thanks.
-
Hi guys, this is probably a very *niche* question, and I don't suppose I'll get many answers, but here's hoping ... :( My program has two components, let's call them ... program.exe and library.dll - library.dll is statically linked to program.exe throughout program.exe's entire lifetime. Suppose a function in program.exe calls a function in library.dll, which allocates some memory using the "new" operator. I've recently discovered that releasing this allocated memory from a function in program.exe causes a crash. You have to release the dynamic memory from the same *module* it was allocated in. Therefore, if I allocated memory using a statement in library.dll, I have to release it using another statement in library.dll, not in program.exe. It took me long enough to figure that out without any documentation, and that's fine, but my problem is as follows: Suppose I have a structure of two nested classes. class A; class B { A a; // contains an instance of A }; Class A is defined in library.dll, class B in program.exe Class B is instanced in the global scope in program.exe. Now, suppose I call a function in class B (program.exe) that then calls a function in class A (library.dll) to allocate some dynamic memory. Class A has a destructor that should theoretically release the memory once the lifetime of the instance "a" expires. When the program closes, this is usually done inside the exit() function when all destructors are executed, when the program is closing. But here comes my problem: Before the program closes, C++ throws an exception as the "delete" operator on the dynamic memory is executing. This happens, as I see it (and hopefully I'm wrong), because C++ somehow treats the "delete" statement that is defined inside library.dll as a code of program.exe because it's calling it from the global destructor. Having a destructor of class A in library.dll for the dynamic memory causes a crash. However, when I define a destructor of class B in program.exe that calls a function in class A to delete the memory, the program ends fine without any crashes. I hope I have made the matter clear, confusing though it may be. Does anyone have the slightest idea what may be going wrong? I'd be very grateful, thanks.
We have projects that have memory allocated and freed, newed and deleted all over the place. I think that perhaps your DLL and EXE are somehow mismatched. One is Debug, other is Release, or if MFC, one is statically linked to MFC and other is using MFC as a DLL. You can check that and possibly your problem will go away. Other option, to avoid the delayed delete calls, is to declare a POINTER to your Class B at global scope, and create (new) it within the context of your program's regular execution (InitInstance in MFC), and delete it before your program is really exiting (wihtin ExitInstance). Then you might be okay that way too.
-
Hi guys, this is probably a very *niche* question, and I don't suppose I'll get many answers, but here's hoping ... :( My program has two components, let's call them ... program.exe and library.dll - library.dll is statically linked to program.exe throughout program.exe's entire lifetime. Suppose a function in program.exe calls a function in library.dll, which allocates some memory using the "new" operator. I've recently discovered that releasing this allocated memory from a function in program.exe causes a crash. You have to release the dynamic memory from the same *module* it was allocated in. Therefore, if I allocated memory using a statement in library.dll, I have to release it using another statement in library.dll, not in program.exe. It took me long enough to figure that out without any documentation, and that's fine, but my problem is as follows: Suppose I have a structure of two nested classes. class A; class B { A a; // contains an instance of A }; Class A is defined in library.dll, class B in program.exe Class B is instanced in the global scope in program.exe. Now, suppose I call a function in class B (program.exe) that then calls a function in class A (library.dll) to allocate some dynamic memory. Class A has a destructor that should theoretically release the memory once the lifetime of the instance "a" expires. When the program closes, this is usually done inside the exit() function when all destructors are executed, when the program is closing. But here comes my problem: Before the program closes, C++ throws an exception as the "delete" operator on the dynamic memory is executing. This happens, as I see it (and hopefully I'm wrong), because C++ somehow treats the "delete" statement that is defined inside library.dll as a code of program.exe because it's calling it from the global destructor. Having a destructor of class A in library.dll for the dynamic memory causes a crash. However, when I define a destructor of class B in program.exe that calls a function in class A to delete the memory, the program ends fine without any crashes. I hope I have made the matter clear, confusing though it may be. Does anyone have the slightest idea what may be going wrong? I'd be very grateful, thanks.
I am with you on this. The guideline that I go by. objects that are instantiated inside a dynamically loaded library must be deleted inside the same library. If the object is deleted inside the program itself, the results are unpredictable. It may work fine, or it may cause a memory leak or even a program crash. If your program redefines new or delete, a program crash is almost guaranteed. Thank You Bo Hunter
-
We have projects that have memory allocated and freed, newed and deleted all over the place. I think that perhaps your DLL and EXE are somehow mismatched. One is Debug, other is Release, or if MFC, one is statically linked to MFC and other is using MFC as a DLL. You can check that and possibly your problem will go away. Other option, to avoid the delayed delete calls, is to declare a POINTER to your Class B at global scope, and create (new) it within the context of your program's regular execution (InitInstance in MFC), and delete it before your program is really exiting (wihtin ExitInstance). Then you might be okay that way too.
-
I am with you on this. The guideline that I go by. objects that are instantiated inside a dynamically loaded library must be deleted inside the same library. If the object is deleted inside the program itself, the results are unpredictable. It may work fine, or it may cause a memory leak or even a program crash. If your program redefines new or delete, a program crash is almost guaranteed. Thank You Bo Hunter
So what's the verdict? This is a really interesting thread and I'd like to know if any conclusions were reached. Based on Peter's description, the memory is getting allocated in the program. Peter, you said that class A was embedded in class B right? And you said that class B was instantiated in the main application right? So essentially, the library contains the class declaration for A but the main application project contains the actual code that runs and instantiated objects, deletes objects, displays data to the console, and so on and so forth. Is that right? I do this all the time with no problems. The class in the library needs to be exported so that the program can compile and link properly. Obviously you've done that else it wouldn't have compiled and linked. But I have never instantiated something in a DLL and then passed the destruction responsibility to another DLL or .exe. That would seem like a strange implementation to me; anyway. I don't know what you mean by the "Delete" statement defined in library.dll. The delete statement is basic C++ syntax. It's not defined in the DLL. I don't know what you mean by saying that. It sounds like your library.dll is simply declaring the class. That has no bearing on where and how the class can be created or destroyed. Any project (dll or the main project) should be able to link to the class declaration in your library, instantiate it's own version of the object and subsequently delete it. Is there any special code in the destructor of Class A? It'd be nice to see some code snips of class B and A so we have some idea of the complexity of the classes, especially what specifically, is being done in the destructor of each class. Oh and some snips of code where you instantiate and delete the object would be nice to see as well.