[omniORB] Questions about the CRT heap and omniORB 2.8.0.

[Mike Bendickson]

I'm struggling a bit with the CRT code generation options in VC++.

I have a DLL that is both a CORBA server and client.  The DLL **hides** all
of the CORBA specific code from the application.

I believe that omniORB is built to use the DLL CRT (/MD for release and /MDd
for debug).  As I understand it, by using the DLL CRT in your app and DLLs,
you can do new/delete, malloc/free across DLL/application boundaries as
those calls will be going against the same heap.  As opposed to statically
linking the CRT where the new/delete, malloc/free use the local heap.

I'm guessing that omniORB needs to be built that way as user code and/or
stub code makes allocations that can be freed in the omniORB DLLs or vise
versa.  Is this correct?

Here's the situation that I'm having.  The application statically links the
CRT.  The DLL, that contains all CORBA specific code, uses the DLL CRT.
Should this work?  I'm getting a Debug Assertion Failure on
_crtIsValidHeapPointer.  I believe that this error occurs when you try to
delete/free a pointer that was allocated on a different heap.

Looking at the Context in the debugger the assertion is happening in:

void
GIOP_S::HandleRequest(CORBA::Boolean byteorder)


on the dispatch call:
.
.
.
if (obj) {
    if (!obj->dispatch(*this,
        (const char *)pd_operation,
        pd_response_expected)) {
.
.
.

I believe I've isolated all omniORB calls to the DLL.  The DLL is built with
a "Use run-time library" option of "Debug Multithreaded DLL".  The
application is built with a "Use run-time library" option of "Debug
Multithreaded".  Based on my understanding it seems like this should work.

If the application is built to use the DLL CRT, everything works fine.  It's
fine if I need to build it that way, I'm just concerned that I'm covering up
some other problem as it seems like this should work.

Thanks,
-Mike