[omniORB] compiling omniORB3 on NT -- Assertion failure

[Andrei Romanov]

As I understand you can easy avoid these problems with mixing Release and
Debug builds by macrodefinition in your MFC project _AFX_NO_DEBUG_CRT.
In the case all memory functions in your Debug build will be compatible with
the same functions in Release builds of another component.

Hope it helps.

Andrei Romanov

> All is clear now.  I was worried when I saw the responses to my response
> since I have about ten applications and nearly two dozen DLL's that
> freely pass heap pointers back and forth.  For example:
> ...
> What makes this clear is the explanation in the "Memory Management and
> the Debug Heap" topic in the MSDN liibrary.  The determination of which
> new and delete operators are invoked is made by the inclusion of
> CRTDBG.h and the presence of the following macro:
>
> #ifdef _DEBUG
> #define new DEBUG_NEW
>
> For the sake of discussion, I will call the case where these are present
> managed allocation and the case where they are not present unmanaged
> allocation.  Managed heap allocation is performed by the runtime library
> as described in the MSDN topic.  In unmanaged allocation, the debug
> version of the operator new override simply invokes malloc and the debug
> version of the operator delete override simply invokes free.  In the
> example above, the concrete factory uses unmanaged allocation but the
> document class invokes the delete operator under managed allocation.
> The reason this works is that the managed allocation delete operator
> checks to see if the block was allocated by an unmanaged new operator
> and skips the assertions if this is true.  This is important because
> third-party DLL's and libraries, such as omniORB or my DLL, may or may
> not use managed heap.  All this is further complicated by the fact that
> the debug and non-debug versions of managed heap are handled
> differently.  The most likely explanation of the problems Ji-Yong
> encountered is that a non-debug managed allocation was made followed by
> an attempt to make a debug managed deallocation.  I would not be
> surprised to discover that Microsoft maintains a separate "heap" in its
> MFC DLL's, but this should not change the way we all deal with normal
> C++ heap.  They clearly recognized this as a problem for multi-threaded
> processes and simply disallow (via assertion failures) inter-thread
> access of MFC objects created on their "heap".
> ...
> Steve Brenneis