memory and DLLs

Started by
3 comments, last by Taulin 21 years, 5 months ago
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!
Advertisement
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 ]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
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!
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

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

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.

This topic is closed to new replies.

Advertisement