DLLs and new/delete allocation 1

[LyMc]

I wrote a program that makes use of a class which stores objects. When it runs out of room it allocates (using "new") a new, larger area, copies the objects over, and then deletes (using "delete") the old space. It works great, and is much used in the code. The class is in a staticly loaded library.

More lately I need to create a DLL to do certain functionality. It is called by the application, and it also makes use of the class (again, statically loaded into the DLL). There seems to be no problem with being able to access any object in the class storage from either the app or the dll (I could be wrong about this; I've not tested it exhaustively); however, when the dll tries to place an object into storage and it has to re-allocate, the delete fails. The place where it fails at in the CRT library source is "_CrtIsValidHeapPointer", and has a comment:

* Go through the heap regions and see if the pointer lies within one
* of the regions of the local heap.
* Pointers from non-local heaps cannot be handled. For example, a
* non-local pointer may come from a DLL that has the CRT linked-in.

Can someone direct me to somewhere where I can read about this? what the rules are? or is there a way to configure the compiler to handle this, perhaps? I've done an hour's worth of looking (here and in Google) and cannot find anything that describes what I'm seeing (or, rather, that I recognize as describing...).

I'm using the MS .NET compiler, with platform SDK only (no MFC, ATL, managed, .NET or what have you).

 

[Cagliostro]

try with compiler option /MD or /MDd

Ion Filipski

 

[LyMc]

OK, Thank you Ion. I have made all the static libraries that I build, and the app main, /MT or /MTd, and the dll "main" code /MD or /MDd. Apparently, though, some other library is not multitasked, as I now get multiple defs from MSVCRT and LIBCMT. If I put msvcrt on the do-not-load list, I get link errors 4217 on a number of the older c library functions I use (string library and some others). Can any of these "warnings" be ignored?

The other libraries I load are version.lib and comctl32.lib, plus whatever standard libraries are loaded.

Is it the "multitaking" part of the option which should fix the dynamic allocation problem?

 

[Cagliostro]

it is an usual way to solve problem with memory from a module when you want to delete/allocate/reallocate it. By the way, you get errors or warnings, I do not understand it from your message.

Ion Filipski

 

[LyMc]

They are all actually warninigs, Ion. It does proceed to create a dll. I'll have to do a spot of testing before I can say whether they can be *safely* ignored or not. I'll get back here on that tomorrow.

 

[Cagliostro]

Ok, don't forget to clean/rebuild when adding new settings.

Ion Filipski

 

[LyMc]

It appears that the raft of linker warnings don't affect the way the program works, so they appear to be ignorable. I imagine the basic problem is that either version.lib or comctl32.lib, or both, is dragging in the non-multithread runtime library, causing the original multi-definition problem, and that the multithreaded and single threaded libraries aren't precisely coordinated, but the results of refusing the single threaded library seems to be able to be lived with.

So, thanks, Ion, for the help. If anyone knows exactly why using the multithreaded form allows the memory management to work properly (the original question), or can cite MS chapter and verse on this, I would be much obliged to hear. I'm always looking to learn a little more.

 

[ArkM]

Try search MSDN with __declspec(thread) keyword (MS extension)...
See also TLS (Thread Local Storage)...

 

[ThomasJansen]

Hi,

I have had similar problems using an MFC app and MFC dll. The problem is that both have their own memory tracker. Memory allocated in the app and freed in the dll (vice versa) will trigger this error since the memory handle to be freed is not known in the dll's memory objects list. This is a warning though and release builds should work fine. To prevent it I made the application responsible for all allocations (it exports a class to the dll to allocate). In this case he problem will not occur.

Hope this helps,

Thomas


Thomas