[omniORB] omniORB and TAO in the same process space

[Friedhelm Wolf]

Hi there,

I guess I'm doing something very weird, but anyway I'd be happy about some
comments on it:

I am using omniORB 4.0.3 on Suse Enterprise Linux 9.3.

I have a running and rather complex system based on CORBA and
using omniORB. I now want to integrate one TAO servant into this
environment.
This system however loads CORBA servants from shared libraries.
The whole mechanism to find and load these needed libraries, includes
CORBA calls (which are served by omniORB CORBA servants).
As a concequence to this I end up having TAO in the same process space.

I found out it, that the initialisation of TAO doesn't work properly.
The only hint I have until now is an omniORB error message, which
seems to occur in the midst of executing TAO code:

omniORB: ERROR -- an invalid buffer pointer is passed to freebuf
of string or object sequence

I found out, that this results from a global error handler function (or
something like that),
void _CORBA_bad_param_freebuf() in omniORB/orbcore/exception.cc


Is there some global error handling in omniORB which might have this effect.
Do you in general advise against the use of two ORBs (from different
vendors) in the
same process?

Cheers,
Friedhelm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070622/3ada94f5/attachment.htm

[Alexandre DENIS]

Post by Friedhelm Wolf
Do you in general advise against the use of two ORBs (from
different vendors) in the same process?

You can't use two ORBs from different vendors in the same process because they
want to use the same namespace (i.e. CORBA::*)

When the application calls e.g. CORBA::ORB_init(), is it supposed to call
omniORB or TAO?

-a.

[Friedhelm Wolf]

Skipped content of type multipart/alternative-------------- next part --------------
#0 CORBA::Object::is_nil_i (obj=0x59afc0) at Unbounded_Value_Sequence_T.h:97
#1 0x0000002a99c42450 in TAO_Policy_Set (this=0x7fbfffd120, rhs=<value optimized out>) at Object.inl:54
#2 0x0000002a99ecb0e9 in TAO_POA_Policy_Set (this=<value optimized out>, rhs=<value optimized out>) at POA_Policy_Set.cpp:28
#3 0x0000002a99e99266 in TAO_POAManager_Factory::create_POAManager (this=0x59b100, id=0x2a99ed0c9e "RootPOAManager", policies=@0x7fbfffd430) at Object_Adapter.inl:24
#4 0x0000002a99e9d869 in TAO_Object_Adapter::open (this=0x59a000) at Objref_VarOut_T.h:54
#5 0x0000002a99c38fa1 in TAO_ORB_Core::root_poa (this=0x5844a0) at memory:271
#6 0x0000002a99e98b02 in TAO_ServantBase::_default_POA (this=<value optimized out>) at Pseudo_VarOut_T.inl:16
#7 0x0000002a99e988f8 in TAO_ServantBase::_create_stub (this=0x583158) at Objref_VarOut_T.h:54
#8 0x0000002a98930754 in POA_ILogger::_this (this=0x582de0) at LoggerS.cpp:1863
#9 0x0000002a989379f7 in CreateInstance (nameOfComponent=0x563b88 "Logger") at Logger.cpp:202
#10 0x0000002a958d0616 in CorbaManager::LoadFromSo (diskPath=0x551f80 "/home/fwolf/SIMSAT4-D3-Pre/install/Registry/", str=0x566350 "Logger") at CorbaManager.cpp:329
#11 0x0000002a958ce2eb in Simsat::Component::CreateFromSo (this=0x567658, diskPath=0x551f80 "/home/fwolf/SIMSAT4-D3-Pre/install/Registry/", name=0x566350 "Logger") at Component.cpp:71
#12 0x0000002a958d8c03 in Simsat::Registry::Create (this=0x567650, typeName=0x566350 "Logger") at Registry.cpp:87
#13 0x0000002a980d6f56 in Kernel_i::CreateNewComponent (this=0x567590, type=0x566350 "Logger") at Kernel.cpp:76
#14 0x0000002a980dc138 in Kernel_i::LoadComponent (this=0x567590, component=@0x7fbfffdee0, reader=0x557848, compName={static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<No data fields>}, _M_p = 0x563b08 "Logger"}, static _S_empty_rep_storage = {0, 0, 8, 0}}) at Kernel.cpp:1003
#15 0x0000002a980dd3f6 in Kernel_i::LoadDictionary (this=0x567590, componentLoader=@0x567650, dic=@0x5675c0, name=0x2a980f6d39 "Services", reader=0x557848) at Kernel.cpp:1211
#16 0x0000002a980d91dd in Kernel_i::Load (this=0x567590, reader=0x557848) at Kernel.cpp:449
#17 0x0000002a96523f0f in _0RL_lcfn_D3700DA5B2A4A204_30000000 (cd=0x7fbfffe2b0, svnt=0x5676c0) at IStructuredDataPersistenceSK.cpp:267
#18 0x0000002a977f6f94 in omni::omniOrbPOA::dispatch () from /home/fwolf/SIMSAT/install/cots/omniORB/lib//libomniORB4.so.0
#19 0x0000002a977db565 in omniLocalIdentity::dispatch () from /home/fwolf/SIMSAT/install/cots/omniORB/lib//libomniORB4.so.0
#20 0x0000002a977e9c1b in omniObjRef::_invoke () from /home/fwolf/SIMSAT/install/cots/omniORB/lib//libomniORB4.so.0
#21 0x0000002a96523f79 in Simsat::_objref_IStructuredDataPersistence::Load (this=0x567ad8, reader=0x557848) at IStructuredDataPersistenceSK.cpp:291
#22 0x0000000000408f30 in LoadKernel () at SimHost.cpp:396
#23 0x0000000000409fc1 in main (argc=10, argv=0x7fbfffe698) at SimHost.cpp:615

[Alexandre DENIS]

I attatched a core dump which shows, that there are TAO calls made
within a omni ORB requests. Please correct me if I misinterpret this
dump (I'm no expert at all), but it seems, that the symbols don't get
mingled. (maybe because the whole TAO stuff is dynamically loaded at
runtime).

This backtrace shows that CORBA::Object::is_nil from omniORB was applied
to a TAO object.

But I guess the problem with the _CORBA_bad_param_freebuf() error is
due to global symbols too and so I better find a way to use the ORBs
in two separate
processes.

Indeed, it would be much better to have different ORBs in different
processes.

-a.

[Friedhelm Wolf]

Alexandre,

fair enough ... you're right ... it's always omniORB which processes the
CORBA calls.
Thanks a lot for your hint.

Friedhelm

Post by Alexandre DENIS

I attatched a core dump which shows, that there are TAO calls made
within a omni ORB requests. Please correct me if I misinterpret this
dump (I'm no expert at all), but it seems, that the symbols don't get
mingled. (maybe because the whole TAO stuff is dynamically loaded at
runtime).

This backtrace shows that CORBA::Object::is_nil from omniORB was applied
to a TAO object.

But I guess the problem with the _CORBA_bad_param_freebuf() error is
due to global symbols too and so I better find a way to use the ORBs
in two separate
processes.

Indeed, it would be much better to have different ORBs in different
processes.
-a.

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

[Duncan Grisby]

Post by Alexandre DENIS

I attatched a core dump which shows, that there are TAO calls made
within a omni ORB requests. Please correct me if I misinterpret this
dump (I'm no expert at all), but it seems, that the symbols don't get
mingled. (maybe because the whole TAO stuff is dynamically loaded at
runtime).

This backtrace shows that CORBA::Object::is_nil from omniORB was applied
to a TAO object.

Actually I don't think it does. Unbounded_Value_Sequence_T.h is not an
omniORB header, so it must be part of TAO.

However, you are right about the general problem. Because of the way the
C++ mapping works, there are inevitably function and type names that
overlap between omniORB and TAO. What happens is entirely at the mercy
of how the runtime linker chooses to resolve symbols. Somewhere along
the line, it is mixing up omniORB and TAO code, and understandably blows
up as a result.

I think it's a lost cause to integrate two different C++ ORBs in one
process.

Cheers,

Duncan.