[omniORB] VC++ new and delete mismatch problem...

[Michael Burbidge]

Our application is a componentized application. It consists of a tiny 
.exe, that basically serves only to bootstrap the process and a few 
hundred components or plug-ins that give our application it's 
functionality. Each of these components is a shared library that is 
loaded on demand. These components link against a common shared library 
that provides underlying infrastructure and runtime facilities. One of 
the things that is provided by this common shared library is a set of 
allocation routines, including global C++ new and delete operators. 
These allocation routines track memory usage in a sophisticated manner 
and provide such functionality as unloading or purging unused plug-ins 
and related data.

I'm writing a new plug-in for our application that uses OmniOrb. It of 
course links against our common shared library and it links against the 
OmniOrb shared libraries (dlls).

The problem comes when a CORBA call is made into this plug-in and 
certain data types are passed as parameters to this method. For 
example, when a CORBA::WString (other types also) object is passed into 
a method of my plu-in, it is allocated within the OmniOrb dlls using 
the new operator. The OmniOrb dlls are picking up the new operator from 
the standard Microsoft runtime libraries.  As we're exiting the call 
from the CORBA method in our plug-in, the proxy code generated by the 
idl compiler (the glue that makes CORBA dispatching work) deletes this 
same object. Since the generated proxy code is all inlined, and we're 
in our plug-in, the delete operator used is from our runtime shared 
library. We immediately crash since the object being deleted was 
allocated using the Microsoft runtime library version of new, but is 
being deallocated using a custom version of delete provided by our 
common shared library code.

Does OmniOrb contain any memory allocation hooks to allow clients to 
provide their own version of memory allocation?

Michael-