[omniORB] Trouble with multiple ORB implementations...
Gerke, Tom
tom.gerke@intel.com
Thu Sep 12 12:08:29 2002
I am using OmniORB2 2.8 on RedHat Linux version 7.3.2.96-110. I am using
gcc compiler version 2.96.
My application dynamically links with the OmniORB2 .so libraries. My
application also links with another .so library, let's call it library
'XXX'. This 'XXX' library in turn utilizes its own ORB, let's call it
'ORB_XXX'. (Library 'XXX' has been dynamically linked to it's own set of
'ORB_XXX' .so libraries.)
(NOTE: I believe that the other ORB is ORBacus 4.05, but I'm not 100% sure.)
When I call a function inside library 'XXX', it calls its own
CORBA::ORB_init() function, in its own 'ORB_XXX' .so library. As this
function continues with its processing, it somewhere deletes a string object
which in turn causes CORBA::string_free() to be called. But, this
CORBA::string_free() call is called in the OmniORB2 .so library.
Why is this? Does it have to do with both ORBs using the "CORBA" namespace?
If so, how would I resolve this?
It ends up core dumping in a call to pthread_mutex_lock(). I imagined that
this core dump was related to the fact that CORBA::string_free() was called
in the OmniORB2 .so library and not in the 'ORB_XXX' .so library. Do you
think the core dump is related to this?
Finally, have you ever, or do you know anyone who has ever, had a
configuration like this (i.e. 2 different dynamically loaded ORB
implementations in the same application, functioning independently of each
other)?
Below you'll find the GDB stack trace from my core dump...
Thanks for any help,
Tom
---- GDB STACK TRACE ----
#0 0x407d00c7 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
#1 0x4207ac18 in free () from /lib/i686/libc.so.6
#2 0x40799486 in __builtin_delete (ptr=0x46c22abd) at
../../gcc/cp/new2.cc:-1
#3 0x407994af in __builtin_vec_delete (ptr=0x46c22abd)
at ../../gcc/cp/new2.cc:-1
#4 0x403065c5 in CORBA::string_free ()
from /home/ist/DTF_Dev/OmniORB/x86_linux/lib/libomniORB2.so.8
#5 0x4674d66a in OB::StrSeqFreebuf ()
from /usr/dialogic/ooc/lib/libOB.so.4.0.5
#6 0x46b5ad2e in OB::StrSeq<int>::length ()
from /usr/dialogic/ooc/lib/libOB.so.4.0.5
#7 0x46b260d0 in OB::Properties::setProperty ()
from /usr/dialogic/ooc/lib/libOB.so.4.0.5
#8 0x46b29945 in OB::Properties::load ()
from /usr/dialogic/ooc/lib/libOB.so.4.0.5
#9 0x46b24c5b in OB::Properties::getDefaultProperties ()
from /usr/dialogic/ooc/lib/libOB.so.4.0.5
#10 0x468e7752 in OBCORBA::ORB_init ()
from /usr/dialogic/ooc/lib/libOB.so.4.0.5
#11 0x468e99e1 in CORBA::ORB_init () from
/usr/dialogic/ooc/lib/libOB.so.4.0.5
#12 0x46363e77 in CCorbaDeviceMapperClient::setupConnection ()
from /usr/lib/libdevmap.so
#13 0x46363aa4 in CCorbaDeviceMapperClient::CCorbaDeviceMapperClient ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/libdevmap.so
#14 0x46365204 in CDeviceMapperClientFactory::getInstance ()
from /usr/lib/libdevmap.so
#15 0x463651ae in dm_getDeviceMapperClient () from /usr/lib/libdevmap.so
#16 0x46364fa5 in dm_getHostAU () from /usr/lib/libdevmap.so
#17 0x462109bc in CCleoSystem::CCleoSystem () from /usr/lib/libdmr4cleo.so
#18 0x46215ef3 in CleoLibraryInitialize () from /usr/lib/libdmr4cleo.so
#19 0x46216070 in CleoCreateSystemObj () from /usr/lib/libdmr4cleo.so
#20 0x460c2bcd in DlgcHost_Cheetah::DeviceInfoData::DeviceInfoData ()
from /usr/lib/libcheetah.so
#21 0x460c2e16 in DlgcHost_Cheetah::DeviceInfoData::GetInstance ()
from /usr/lib/libcheetah.so
#22 0x45fd59f9 in dm3cc_QueryDevice () from /usr/lib/libdm3cc.so
#23 0x40c3bca1 in gcdb_DeviceNameToCCLibID () from /usr/lib/libgc.so
#24 0x40c31997 in gc_open_networkdevice () from /usr/lib/libgc.so
#25 0x40c313da in gc_OpenEx () from /usr/lib/libgc.so
#26 0x40c311e3 in gc_Open () from /usr/lib/libgc.so
#27 0x41f718f4 in ?? ()
#28 0x41f6f6cd in ?? ()
#29 0x4066efc9 in DTF_R4_DM3_Test::start (this=0x8330720, level=1)
at ../../src/TestAdapter/Test/DTF_R4_DM3_Test.cpp:250
#30 0x4066f1d6 in DTF_R4_DM3_Test::finish (this=0x8330720, level=104)