[omniORB] Assertion failure in giopImpl12 (omniORB4)

[Chris Newbold]

We've got a relatively reproducable scenario that causes omniORB4 to hit
an internal assertion. Here's the assert message:

        Nov 22 13:08:54.144519 rcpd[30504:30671]: omniORB D
        omniORB: Assertion failed.  This indicates a bug in the
        application using omniORB, or maybe in omniORB itself. e.g.
        using the ORB after it has been shut down.
        file:/u/jfardo/work/orb4_main/src/lib/omniORB/orbcore/giopImpl12.cc
        line: 322
        info: g->pd_strand->servers.next != &g->pd_strand->servers
        
And here's the backtrace of the offending thread (I've chopped it down
to 20 frames, since the remaining 30 or so aren't relevant):

          #0   0x40441c0f  pthread_sighandler_rt+175
          #1   0x404823f0  __restore_rt
          #2   0x404824c1  __kill+17
          #3   0x40441f17  raise+39
          #4   0x404839b5  abort+225
          #5   0x4029dbd8  omniORB::fatalException::fatalException(char
        const *,
        int, char const *)+52
          #6   0x40298859  omni::assertFail(char const *, int, char
        const *)+201
          #7   0x402d78bc 
        omni::giopImpl12::inputQueueMessage(omni::giopStream
        *, omni::giopStream_Buffer *)+840
          #8   0x402d803b 
        omni::giopImpl12::inputReplyBegin(omni::giopStream *,
        void (*)(omni::giopStream *))+347
          #9   0x402d812c 
        omni::giopImpl12::inputMessageBegin(omni::giopStream
        *, void (*)(omni::giopStream *))+44
          #10  0x402cba83  omni::GIOP_C::ReceiveReply(void)+99
          #11  0x402b6842 
        omniRemoteIdentity::dispatch(omniCallDescriptor
        &)+254
          #12  0x4029bcbd  omniObjRef::_invoke(omniCallDescriptor &,
        bool)+189
          #13  0x08b5fba7 
        IF::_objref_ManagedInterface::ifIndex(void)+167
          #14  0x09085479
        mpls2::RequestExecutor::EnqueueRequest(mpls2::RmRequest *,
        mpls2::_objref_ManagedInterface *, util::SimpleMutex *&, void
        *&)+217
          #15  0x09095788 
        mpls2::RmRequest::_DoEnqueue(util::SimpleMutex *&,
        bool)+56
          #16  0x0911364d  mpls2::AsyncRequest::Enqueue(bool)+233
          #17  0x090f024f  mplstmgr::RmRequest::Submit(void)+63
          #18  0x09112efa
        mplstmgr::VpnTxEndpoint::_Disconnect(std::_Rb_tree_iterator<std::pair<mp
        lstmgr::Lsp *const, xconnect::TxEndpointHandle>,
        std::pair<mplstmgr::Lsp
        *const, xconnect::TxEndpointHandle> &, std::pair<mplstmgr::Lsp
        *const,
        xconnect::TxEndpointHandle> *> &, mpls2::Request *, bool)+1050
          #19  0x090ffd0b
        mplstmgr::TxEndpointBase::LowerLspDeleted(mplstmgr::Lsp *)+923
          #20  0x091001c4
        mplstmgr::TxEndpointBase::LowerTunnelDeleted(void)+404
        
This seems to be triggered by killing the server process to which we're
trying to make this call; it's likely that the call is already in
progress at the time the server process goes down.

I looked at giopImpl12 a little, and it doesn't look like this could
really be caused by an application-level error (aside from memory
corruption), though I had trouble follow the code...
        

-- 
====( Chris Newbold  <cnewbold@laurelnetworks.com> )==========================
      Laurel Networks, Inc. voice: +1 412 809 4200 fax: +1 412 809 4201
"If you fool around with a thing for very long you will screw it up." --Murphy
------------------------------------------------------------------------------