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

[Luke Deller]

Hi Michael,

To get the omniORB dlls to use a different implementation of the new and
delete operators, you need to relink the omniORB dlls against a library
containing your alternative operators.

Put a reference to your library at the front of the definitions of
"imps" and "dbugimps" in mk/mklib.mk and src/lib/omnithread/dir.mk .

To be able to compile the tools that come with omniORB, you'll also want
to put a reference to your library in the definition of OMNIORB_LIB and
OMNIORB_LIB_NODYN in mk/win32.mk .

Regards,
Luke.

On Fri, 2005-04-01 at 09:47 -0800, Michael Burbidge wrote:
> 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-