On 12/11/13 18:35, Adriano dos Santos Fernandes wrote: > (gdb) frame 3 > #3 0x00007ffff45f7b4e in ~Mutex (this=0x7fffec5a10a8) at > /home/asfernandes/fb/dev/trunk.git/src/include/../common/classes/locks.h:217 > 217 fb_assert(lockCount == 0); > > Note in the moment of the print, the assert satisfies. Probably some > race condition happened: > > (gdb) print this->lockCount > $1 = 0 > > I then restarted and ran the RI series again and it passed. > > My tree is not the latest, it's in "Fixed issues noticed by Claudio" > commit with unrelated changes.
Adriano, that's known bug. Races in ~SyncObject(). Thread A waits for SyncObject, thread B releases it (taking helper mutex for it) and goes to sleep before releasing that mutex. Thread A acquires SyncObject and destroys it. Thread A does not need that mutex when notified by thread B that SyncObject is released by thread B. Therefore in dtor mutex is busy. Probably for linux futex-based mutexes the simplest way is to ignore an error cause mutexes are not kernel objects, i.e. we have no resource leak when not release mutex. But not sure that this is good for all posix systems. We discussed it with Vlad and still have no good idea how to fix that performance efficiently. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
