[omniORB] omniORB 2.6.1: Server crash

[Sai-Lai Lo]

The stack trace looks suspicous. I notice the proxy object is doing a
resetRopeAndKey(). This only happens when something has gone wrong with
this invocation, i.e. COMM failure or OBJECT_NOT_EXIST, AND the proxy knows
a previous location forward has been received. The resetRopeAndKey() is
to reset the object reference back to the original location before
retrying. 

Now, did the visibroker server send out a LOCATION FORWARD message
previously? If you turn up the omniORB::traceLevel to over 10, the ORB
would print a message "GIOP::LOCATION_FORWARD: retry request." if it
receives a LOCATION_FORWARD message.

If the visibroker server does not send out a LOCATION FORWARD, then somehow
the flag which tells whether this object has received a location forward is
incorrect. The flag is stored in the variable _0RL_fwd in the stack frame of
_proxy_itccClient::sync_request(). A straight forward explanation is that
you have a stack overflow or something has mess up the stack. 

Sai-Lai


>>>>> Jan Lessner writes:

> Hi omniORBs
> I just ran into a server crash which seems to be related to some very
> deep down details of omniORB. It occured when calling a VisiBroker
> server from an omniORB server but it doesn't look as if it were an
> interoparability problem. The invoked method is not oneway and causes
> the contacted server to exit. This situation seems to mess up some
> clean-up work in the caller process. Here's the stack trace, maybe any
> of you pros can tell something about it. I checked the application with
> Purify as well and there is nothing suspicious going on before the
> actual crash.
> If the problem may be solved in a newer version of omniORB, just let me
> know.

> Regards,
> Jan Lessner, C-LAB


> =>[1] _CORBA_Sequence<IOP::TaggedProfile>::length(0x0, 0xef66a888,
> 0xef7fac24, 0x30594, 0x164dd, 0xef608c54), at 0xef67d5f8
>   [2] static ropeFactory::iopProfilesToRope(0x0, 0xee40efe8, 0xee40efe4,
> 0xee40efec, 0x0, 0xef4a0cd0), at 0xef67c108
>   [3] omniObject::resetRopeAndKey(0x7b630, 0x2, 0x2008, 0x0, 0x0,
> 0x7b968), at 0xef66a958
>   [4] _proxy_itccClient::sync_request(this = 0x7b628, rcvr = 478648, id
> = 0x77128 "cobra-ctrl", body =  CLASS ), line 3419 in
> "sun5/../itccSK.cpp"
>   [5] RegisteredClient::sync_request(this = 0x7b9d8, rcvr = 478648,
> opname = 0x77128 "cobra-ctrl", body =  CLASS ), line 254 in
> "sun5/../itcsrv.cpp"
>   [6] Replier::request(this = 0x74dd8, opname = 0x77128 "cobra-ctrl",
> body =  CLASS ), line 329 in "sun5/../itcsrv.cpp"
>   [7] PendingAsync::deliver(this = 0x90788, b =  CLASS ), line 409 in
> "sun5/../itcsrv.cpp"
>   [8] itccServer_i::sync_request(this = 0x7a448, clientid = 591128, msg
> = 0x770b0 "cobra-ctrl", body =  CLASS ), line 1005 in
> "sun5/../itcsrv.cpp"
>   [9] _sk_itccServer::dispatch(this = 0x7a448, _0RL_s =  CLASS , _0RL_op
> = 0xee40fb5c "sync_request", _0RL_response_expected = '^A'), line 2392
> in "sun5/../itccSK.cpp"
>   [10] GIOP_S::HandleRequest(0xee40fb0c, 0x0, 0x0, 0x1, 0x8, 0x0), at
> 0xef6515a0
>   [11] static GIOP_S::dispatcher(0x7bc48, 0xef496b60, 0xef6dc6c8,
> 0x77018, 0x0, 0xef4157e4), at 0xef650664
> dbx: objectfile
> '/globals/p1/lip/lipdevel/omniORB/2.6.1/src/lib/omniORB2/sharedlib/tcpSocketMTfactory.o'
> is not in ELF format
>   [0] , at 
> dbx: objectfile
> '/globals/p1/lip/lipdevel/omniORB/2.6.1/src/lib/omniORB2/sharedlib/corbaOrb.o'
> is not in ELF format
>   [0] , at 
>   [14] tcpSocketWorker::run(0x7bce0, 0x7bc48, 0x76258, 0x76258, 0x77020,
> 0x3), at 0xef6dd44c
> dbx: objectfile
> '/globals/p1/lip/lipdevel/omniORB/2.6.1/src/lib/omnithread/sharedlib/posix.o'
> is not in ELF format
>   [0] , at



-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 223 343000
Cambridge CB2 1QA                     Fax:   +44 223 313542
ENGLAND