[omniORB] question regarding ORB initialization in DLLs and some general problems

[Andrew Buza]

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)?

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.

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.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090619/cf79beee/attachment.htm

[William Bauder]

-----Original Message-----
From: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Andrew Buza
Sent: Friday, June 19, 2009 5:39 PM
To: omniORB-***@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

[Andrew Buza]

Post by William Bauder
-----Original Message-----
*Sent:* Friday, June 19, 2009 5:39 PM
*Subject:* [omniORB] question regarding ORB initialization in DLLs and
somegeneral problems
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.

Peeking at the symbol table of the DLL shows that it does contain overloaded
new[] & delete[] operators. However, they aren't declared in the headers
anywhere that I can find.

In any case it seems the problems I'm having aren't anything specific with
omniORB so I'll take my questions to a more general audience.

Thanks for your help, everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090622/586d1858/attachment.htm