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

[Sai-Lai Lo]

Could there be memory corruption happening in your program? It is always the
case that only 1 thread is doing rdlock and rdunlock on the server side.
Race condition seems unlikely.

I found njamd quite useful in quickly alert one to illegal access to memory.

Sai-Lai


----- Original Message -----
From: "Chris Newbold" <cnewbold@laurelnetworks.com>
To: <omniorb-list@uk.research.att.com>
Cc: <mja@laurelnetworks.com>
Sent: Wednesday, August 15, 2001 3:15 PM
Subject: [omniORB] Assertion in Strand::Sync::RdUnlock() under stress


> 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.
>
>
>
>
>
>
>