[omniORB] question regarding ORB initialization in DLLs and somegeneral problems

[William Bauder]

-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Andrew Buza
Sent: Friday, June 19, 2009 5:39 PM
To: omniORB-list at omniorb-support.com
Subject: [omniORB] question regarding ORB initialization in DLLs and
somegeneral problems


I have multiple DLLs (used as extensions to a 3rd party application) that
use omniORB and I'm having quite a bit of trouble getting everything
working. I've read section 4.5.1 (ORB initialization) of the CORBA
architecture spec, but I'm not sure what the correct way to initialize
omniORB is when it's used by multiple DLLs loaded by the same process. 

For instance, should each library call ORB_init or must it be done only once
(and the resulting ORB_ptr exported to other dlls in some way)? 
 
The ORB is a singleton - it's created by the first call to ORB_init(), and
each subsequent call to ORB_init() should return a reference to the same
object - you shouldn't need to export the reference if everything that needs
the ORB is calling ORB_init().  The one thing that you might need to do is
to make sure that you get the ORB initialized with every argument/option
that you need before some other piece of code gets to it. 


Right now my project is a mess. When linking to omniorb statically, ORB_init
will cause an access violation in logiostream.cc:516 (a call to fputs), and
when linked dynamically it will cause the same when calling delete[] in any
CORBA sequence. If I move back to omniORB-4.1.0 I no longer have problems
with initalization and destruction, but calling methods of *_vars passed
across module boundaries will cause access violations in omni_mutex::lock.  
 
Well, a CORBA sequence isn't an array - it's a just a class that overrides
operator[] - so delete should be used, not delete[].  Or you could just
stick with the _var and _ptr types.

I've made sure that everything is linking with the correct runtime library
as mentioned in the wiki. I feel like I must be doing something
fundamentally wrong, but I'm not sure exactly what that might be -- any
suggestions would be welcome. 
 
Check what the other DLLs are linked against.  (dumpbin /imports [dll
name]).  I had a problem with libraries using different c runtime libraries
a few years ago.  I don't have the code anymore, but as I remember, it
involved some creative rearranging of includes and linking.  However, I
think that it produced link errors, not runtime problems, so if you're able
to build, you're probably ok. 

I'm using omniORB-4.1.3 (compiled with /Zc:wchar_t) and msvc 7.1.6030. The
same projects are also built with msvc 8 and work fine. The application that
loads my DLLs (Adobe InDesign) appears to be involved in (de)allocation in
some way since one of its dlls appears in the call stack between the call to
operator delete[] in my code and the implementation in ntdll.dll. Might this
be the source of some of my problems? 
 
That sounds like someone snuck an operator[] delete or #defined free
somewhere. Check the header(s) for the offending dll.
 
Thanks for any help anyone can provide, even if it's just a pointer to some
information or a better place for these sorts of questions.

If you have other libraries that are using omniorb, I would try to confirm
that everything is building against the same omniorb that you are using.
Some sort of binary incompatability would explain the random problems that
you described.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090622/a0bbb2eb/attachment.htm