[omniORB] Assertion in Strand::Sync::RdUnlock() under stress

[Chris Newbold]

We're currently using omniORB 3.03 patch 7, running on Red Hat Linux
6.x. The ORB and all related code was built with gcc 2.95.2.

During a stress test run for our application, omniORB failed with an
assertion in Strand::Sync::RdUnlock(); here's the backtrace:

#0   0x08a8a7cf  CoreSigHandler+299
#1   0x403c0552  pthread_sighandler+194
#2   0x403e9b18  __restore
#3   0x403e9bf1  __kill+17
#4   0x403eaf62  abort+206
#5   0x4024479f  omniORB::fatalException::fatalException(char const *,
int, char const *)+55
#6   0x402186d8  omni::assertFail(char const *, int, char const *)+216
#7   0x40238994  Strand::Sync::RdUnlock(bool)+80
#8   0x4023754d  NetBufferedStream::RdUnlock(void)+77
#9   0x402368f3  NetBufferedStream::~NetBufferedStream(void)+35
#10  0x4022a6dc  GIOP_S::~GIOP_S(void)+172
#11  0x4022b13c  GIOP_S::dispatcher(Strand *)+1164
#12  0x4024a119  tcpSocketWorker::_realRun(void *)+101
#13  0x402611d2  omniORB::giopServerThreadWrapper::run(void (*)(void *),
void *)+30
#14  0x4024a0a4  tcpSocketWorker::run(void *)+48
#15  0x4029802a  omni_thread_wrapper+170

I've spent some time poking around in the code, but have come to only a
few very cursory conclusions: 1) hitting this assertion would seem to
indicate that there was a sequence of unbalanced calles to RdLock() and
RdUnlock(); 2) the use of RdLock() and RdUnlock() in the request
handling path appears to be trivial (and error-free); 3) this could
possibly be caused by unintended concurrency on the underlying Strand;
4) it could just be dodgy exception handling code generated by the
compiler (which burns us a new way each week...)

Any suggestions would be appriciated.

-Chris Newbold
Laurel Networks, Inc.