[omniORB] assert on proxyObjectFactory failed

[Mircea Gherzan]

Hi,

I'm having trouble (on the client) narrowing the right object reference.
It seems that the OMNIORB_ASSERT right after proxyObjectFactory::lookup
fails (omniInternal.cc). The calling code is located in the
__constructor__ function of a shared library, loaded at startup, NOT
with dlopen.

I'm using omniORB 4.0.6 from Debian Sid.

Please, can somebody help me?

Thanks!
--
Mircea Gherzan
Faculty of Automatic Control and Computers
Politehnica University of Bucharest
-------------- next part --------------
wumpus.cpp:58 ORB init
omniORB: Distribution date: Thu Apr 14 17:19:57 BST 2005 dgrisby
omniORB: My addresses are:
omniORB: 127.0.0.1
omniORB: 10.140.50.90
omniORB: Maximum supported GIOP version is 1.2
omniORB: Native char code sets: ISO-8859-1 UTF-8.
omniORB: Transmission char code sets: ISO-8859-1(1.2) ISO-8859-1(1.1) ISO-8859-1(1.0) UTF-8(1.2) UTF-8(1.1).
omniORB: Native wide char code sets: UTF-16.
omniORB: Transmission wide char code sets: UTF-16(1.2).
omniORB: Initialising omniDynamic library.
omniORB: Current configuration is as follows:
omniORB: DefaultInitRef (file) = corbaloc::
omniORB: DefaultInitRef (args) =
omniORB: abortOnInternalError = 0
omniORB: acceptBiDirectionalGIOP = 0
omniORB: acceptMisalignedTcIndirections = 0
omniORB: bootstrapAgentHostname =
omniORB: bootstrapAgentPort = 900
omniORB: clientCallTimeOutPeriod = 0
omniORB: clientTransportRule = * unix,ssl,tcp
omniORB: diiThrowsSysExceptions = 0
omniORB: dumpConfiguration = 0
omniORB: endPoint = giop:tcp::
omniORB: endPointPublishAllIFs = 0
omniORB: giopMaxMsgSize = 2097152
omniORB: giopTargetAddressMode = KeyAddr
omniORB: id = omniORB4
omniORB: inConScanPeriod = 180
omniORB: lcdMode = 0
omniORB: maxGIOPConnectionPerServer = 5
omniORB: maxGIOPVersion = 1.2
omniORB: maxInterleavedCallsPerConnection = 5
omniORB: maxServerThreadPerConnection = 100
omniORB: maxServerThreadPoolSize = 100
omniORB: nativeCharCodeSet = ISO-8859-1
omniORB: nativeWCharCodeSet = UTF-16
omniORB: objectTableSize = 0
omniORB: offerBiDirectionalGIOP = 0
omniORB: omniORB_27_CompatibleAnyExtraction = 0
omniORB: oneCallPerConnection = 1
omniORB: outConScanPeriod = 120
omniORB: poaHoldRequestTimeout = 0
omniORB: poaUniquePersistentSystemIds = 1
omniORB: principal = [Null]
omniORB: scanGranularity = 5
omniORB: serverCallTimeOutPeriod = 0
omniORB: serverTransportRule = * unix,ssl,tcp
omniORB: strictIIOP = 1
omniORB: supportBootstrapAgent = 0
omniORB: supportCurrent = 1
omniORB: supportPerThreadTimeOut = 0
omniORB: tcAliasExpand = 0
omniORB: threadPerConnectionLowerLimit = 9000
omniORB: threadPerConnectionPolicy = 1
omniORB: threadPerConnectionUpperLimit = 10000
omniORB: threadPoolWatchConnection = 1
omniORB: traceExceptions = 1
omniORB: traceInvocations = 0
omniORB: traceLevel = 25
omniORB: traceThreadId = 0
omniORB: unixTransportDirectory = /tmp/omni-%u
omniORB: unixTransportPermission = 777
omniORB: useTypeCodeIndirections = 1
omniORB: verifyObjectExistsAndType = 1
wumpus.cpp:61 Getting object reference
omniORB: Creating ref to remote: root/my poa<Server>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
wumpus.cpp:64 Narrowing
omniORB: Client attempt to connect to giop:tcp:10.230.168.91:9000
omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 1
omniORB: Scavenger task execute.
omniORB: Client opened connection to giop:tcp:10.230.168.91:9000
omniORB: sendChunk: to giop:tcp:10.230.168.91:9000 92 bytes
omniORB: inputMessage: from giop:tcp:10.230.168.91:9000 25 bytes
omniORB: Assertion failed. This indicates a bug in the application using
omniORB, or maybe in omniORB itself.
file: ../../../../../src/lib/omniORB/orbcore/omniInternal.cc
line: 1009
info: pof
omniORB: omniRemoteIdentity deleted.
omniORB: ObjRef() -- deleted.
wumpus.cpp:79 pof
wumpus.cpp:82 Checking for NULL reference

[Duncan Grisby]

Post by Mircea Gherzan
I'm having trouble (on the client) narrowing the right object reference.
It seems that the OMNIORB_ASSERT right after proxyObjectFactory::lookup
fails (omniInternal.cc). The calling code is located in the
__constructor__ function of a shared library, loaded at startup, NOT
with dlopen.

Where are the CORBA stubs for the types you are using? The problem is
that the stubs containing the proxy object factories have not been
loaded by the time your code tries to narrow an object reference. If the
stubs are in the same shared library as your constructor code, the C++
runtime has clearly decided to execute your constructor before it runs
the C++ static initalisers that set up the factories.

I'm not sure what to suggest, other than to defer whatever you're doing
until after the shared library is completely loaded. Trying to do
anything non-trivial at library load time is fraught with dependency
difficulties.

Cheers,

Duncan.

[Mircea Gherzan]

Thank you for your reply. The stubs are compiled in the same shared
library. I need to have the ORB and stubs ready right after the library
is loaded, so placing the code in a constructor was obvious.

The workaround I found is described in the following mail:

http://www.omniorb-support.com/pipermail/omniorb-list/2000-June/015563.html

However, there is no need to create the _pof_InterfaceName object *right
after* ORB_init. It's enough to have it before the _narrow() or any
other method that creates an InterfaceName_var.

Cheers,
Mircea

Post by Duncan Grisby

Post by Mircea Gherzan
I'm having trouble (on the client) narrowing the right object reference.
It seems that the OMNIORB_ASSERT right after proxyObjectFactory::lookup
fails (omniInternal.cc). The calling code is located in the
__constructor__ function of a shared library, loaded at startup, NOT
with dlopen.

Where are the CORBA stubs for the types you are using? The problem is
that the stubs containing the proxy object factories have not been
loaded by the time your code tries to narrow an object reference. If the
stubs are in the same shared library as your constructor code, the C++
runtime has clearly decided to execute your constructor before it runs
the C++ static initalisers that set up the factories.
I'm not sure what to suggest, other than to defer whatever you're doing
until after the shared library is completely loaded. Trying to do
anything non-trivial at library load time is fraught with dependency
difficulties.
Cheers,
Duncan.