Memory allocation across the Dlls

Hi All,

I have been facing some problem with the memory allocation&deallocation across the dlls.

For clarity I'm describing my problem bit elabarated:

I have a COM Dll, which intern uses two dlls.

(UI) <-----> COM_DLL<---->BusinessLogic.dll<--->Communication.dll.

The memory allocated in communicationDll several places and freed in BusinessLogicDll several places, but when the ComDll is in release mode, and the applicatoin is crashes.

But the application is built in Debug mode, everything goes fine. Also I have three versions of UI application two with MFC support and one without MFC support.

I'm facing problem only with the UI-application built without MFC support, with other two absolutely no problems.

I'm pulling my hair, how the MFC support to the UI-Appln affects the behaviur of the COMDll.

To solve the issue, the only known solution is to free the memory in the same dll where it was allocated. But that is too tough for me because, I need to identify and export so many functoins to free the memory. I'm asking you to please let me know if there is some other way to tackle the problem.

thanks in advance,

Raja Pratap

Visual C++14

Not sure if I understand this correctly but you are saying that ComDLL is in release mode and the other dlls are in debug mode If it is so then it simply cannot work. All dlls must be build using the same configuration otherwise a lot of problems will appear.

There was a similar problem in this forum or maybe in the VC General forum within the past month, but I forget what the subject was and such. I think there was a problem with a STL class that allocated memory in a DLL and freed memory in the application.

I know that there have been problems in the past with memory allocations/deallocations across a DLL and the application. I am not sure of the problem currently. I assume that any problems that currently exist is documented somewhere, but for VC 6, it was only described in a KB article. I posted a link to the KB article in the prior thread, but it was ignored, so I assume it is not currently relevant.

Are you building your UI-application using static libraries If so, then try dynamic libraries.

Mike Danes wrote:
All dlls must be build using the same configuration otherwise a lot of problems will appear.

Not sure if I understand this correctly but you seem to be saying that we must have debug and release versions of every DLL we use. Is that what you mean

I'm guessing that this is related to one of the following:

You are freeing memory which has already been free'd, or freeing pointers that were never allocated

Is the application multi-threaded If not; is it possible that two or more deallocations are run on the same piece of memory somehow )

You are mixing debug and realease builds, and specifically debug and release runtime libraries

Make sure that you've got the same non-debug CRT library selected for all parts of the project in release build
Likewise, make sure that all use the debug CRT for debug builds
Also, don't mix debug build dlls with a release application (or the other way around)

You've got a heap corruption (possibly due to a buffer overflow), which obscures the memory allocation information in release build

"I know that there have been problems in the past with memory allocations/deallocations across a DLL and the application. I am not sure of the problem currently."

Yes, it is still a problem. You cannot mix CRT versions (Debug/Release/Static/Dynamic/different versions like 7.0, 7.1, 8.0) unless you are very careful about what you are doing.

If you allocate memory using malloc or new with a runtime you must make sure that you free that memory using the same runtime.
CRT defined structures/classes may have different memory layouts in different runtime versions so if you pass such an object across DLLs you must make sure that every DLL that gets to see the object uses the same runtime.
The file descriptors used by I/O functions like _open, _read, _write and _close cannot be used with different runtimes. Each runtime has its own file tables.

1 and 2 obviously affect STL as well and other things like FILE/fopen/fclose. 3 is probably a rare case.

Mike Danes wrote:

Yes, it is still a problem. You cannot mix CRT versions (Debug/Release/Static/Dynamic/different versions like 7.0, 7.1, 8.0) unless you are very careful about what you are doing.

If you allocate memory using malloc or new with a runtime you must make sure that you free that memory using the same runtime.

CRT defined structures/classes may have different memory layouts in different runtime versions so if you pass such an object across DLLs you must make sure that every DLL that gets to see the object uses the same runtime.

The file descriptors used by I/O functions like _open, _read, _write and _close cannot be used with different runtimes. Each runtime has its own file tables.

That seems to me to be a good explanation of the problem/solution.