From: Deepak C. <dch...@gm...> - 2008-09-25 07:58:26
|
Hello, I have been able to use some MinGW compiled dll files in my MSVC++ application, but when the dlls and the applications are allocation memory of the heap and passing to one another, I get heap corruption errors (crashes) in my MSVC++ application. I did a bit of reading, and it seems that this is a memory alignment issue. I tried using _aligned_malloc( size, 16 ), but that did not resolve the problem. Is there some standard way for dealing with this? Thanks. |
From: Marc V. <vai...@fa...> - 2008-09-25 14:00:12
|
On Thu, Sep 25, 2008 at 12:58:20AM -0700, Deepak Chandran wrote: > Hello, > > I have been able to use some MinGW compiled dll files in my MSVC++ > application, but when the dlls and the applications are allocation > memory of the heap and passing to one another, I get heap corruption > errors (crashes) in my MSVC++ application. For a given data structure, you must keep your allocations/deallocations on *only* one side of the DLL boundary, otherwise you will get heap violations. You can't be guaranteed of the same runtime allocator on both sides. E.g. if a DLL function returns data that it allocates, you must provide a function in the DLL interface to deallocate it. This is important even when staying withing the world of MSVC clients and dlls. Also, if you are writing C++ interfaces, you should read: http://aegisknight.org/cppinterface.html Best, Marc |
From: John B. <joh...@ho...> - 2008-09-25 14:53:37
|
On Thu, 25 Sep 2008 10:00:01 -0400, Marc Vaillant wrote: > > > On Thu, Sep 25, 2008 at 12:58:20AM -0700, Deepak Chandran wrote: >> Hello, >> >> I have been able to use some MinGW compiled dll files in my MSVC++ >> application, but when the dlls and the applications are allocation >> memory of the heap and passing to one another, I get heap corruption >> errors (crashes) in my MSVC++ application. > > For a given data structure, you must keep your allocations/deallocations > on *only* one side of the DLL boundary, otherwise you will get heap > violations. You can't be guaranteed of the same runtime allocator on > both sides. E.g. if a DLL function returns data that it allocates, you > must provide a function in the DLL interface to deallocate it. This is > important even when staying withing the world of MSVC clients and dlls. > > Also, if you are writing C++ interfaces, you should read: > > http://aegisknight.org/cppinterface.html > Does this rule apply if you use Win32 functions GlobalAlloc() and GlobalFree() instead of malloc() and free()? _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live. http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/ |
From: Brian D. <br...@de...> - 2008-09-25 16:16:08
|
Deepak Chandran wrote: > I have been able to use some MinGW compiled dll files in my MSVC++ > application, but when the dlls and the applications are allocation > memory of the heap and passing to one another, I get heap corruption > errors (crashes) in my MSVC++ application. I did a bit of reading, and > it seems that this is a memory alignment issue. I tried using > _aligned_malloc( size, 16 ), but that did not resolve the problem. Is > there some standard way for dealing with this? I doubt it's alignment, but rather the fact that the MSVC app is using a different version of the MS runtime (such as MSVCRT80.DLL) whereas MinGW uses MSVCRT.DLL. If you want to be able to malloc/free across modules like that then they have to be managed by the same heap manager, i.e. the same runtime. So either hack up MinGW to use the same runtime as the rest of the code, or change your API so all malloc/free happens on the same side of the fence. Brian |
From: Keith M. <kei...@us...> - 2008-09-25 22:16:34
|
On Thursday 25 September 2008 17:16:00 Brian Dessent wrote: > I doubt it's alignment, but rather the fact that the MSVC app is > using a different version of the MS runtime (such as MSVCRT80.DLL) > whereas MinGW uses MSVCRT.DLL. If you want to be able to > malloc/free across modules like that then they have to be managed > by the same heap manager, i.e. the same runtime. So either hack up > MinGW to use the same runtime as the rest of the code... Hack up? See http://www.mingw.org/node/25#comment-106 for details of a way to achieve this cleanly and reversibly; just watch out for stray white space in your specs files, as noted in another recent thread, on this list: http://thread.gmane.org/gmane.comp.gnu.mingw.user/27606/focus=27699 Regards, Keith. |