Archived

This topic is now archived and is closed to further replies.

Taulin

memory and DLLs

Recommended Posts

Wow, I got a stumper. One part of an app I am writing converts 1bit mask bitmaps to 4 bit. So the code, located in a DLL, looks like this : ... BYTE* pNewImageData = NULL; ... ... pNewImageData = new BYTE[ newImageSize ]; ... ... delete[] pNewImageData; The problem is if I allocate the memory in a different scope, it blows up when I delete it: ... BYTE* pNewImageData = NULL; ... if ( AllIsWell ) { .... pNewImageData = new BYTE[ newImageSize ]; .... } ... ... delete[] pNewImageData; // Blows up! Do any of you here reocognize any stupid mistakes I making? What is more weird, if I allocate the memory in the base scope (like in the first example), it does not blow up, but the newly created mask is really messed up. Thanks!

Share this post


Link to post
Share on other sites
Memory allocated by a DLL must be deallocated by the same DLL.
Objects constructed by a DLL must be destroyed by the same DLL.

Export a function that does the cleanup from within the DLL.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Share this post


Link to post
Share on other sites
Thanks for the reply, however I am allocating and deleting the memory in the same function scope. It is a member function of a Bitmap wrapper I wrote, which itself is also being created and destroyed inside the DLL.

A very curious problem indeed. I just hope my description is good enough. Again, thanks for the help!

Share this post


Link to post
Share on other sites
1) Slight correction to what Fruny wrote:

If memory allocated in a DLL is to be released in the client application, then the version of the C runtime library used by the DLL **must** be *the same* as the one used by the client app.

The DLL becomes part of the process and shares its address space and its allocs come from the same heap so it is actually ok to delete in the client. However different versions of the CRT have different memory block headers so releasing with the wrong deallocator causes all sorts of spectacular problems.

As Fruny suggests though, it does make sense to make a "free" function for any alloc in the DLL to remove the requirement on the client code (and coder) remembering to use the correct version of the CRT.


2) There doesn''t appear to be any problem with the code posted - I''ve done similar in plenty of DLLs without issue. I suspect the problem is elsewhere.


3) Define "blows up" for us. Try using the DEBUG version of the C runtime library - do you get any asserts ?

a. "DAMAGE" is when you''ve written past an allocated block a small bit

b. Asserts about the memory managers linked list often mean you''ve written past the end of an allocated block by a large amount or have randomly trashed memory.

c. Access violations and other assert can be the result of doing a double free. Try using a "safe delete", if the problem stops, find out why the higher level code is calling twice.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
DAMAGE is what I am getting, and it happens on the delete. Much like when you delete a small array thinking it is bigger. Thanks for looking everyone, and the info about DLLs. The code, especially the routine in question, really is as simple as I posted. I was just hoping a second pair of eyes may notice a stupid mistake.

Share this post


Link to post
Share on other sites