check_lockManager test crashes in RHEL5

[GoogleCodeExporter]

What steps will reproduce the problem?

1. compile in RHEL5 2.6.18-164.el5, glibc 2.5 and run test

What is the expected output? What do you see instead?

*** glibc detected ***
stasis-read-only/build/test/stasis/check_lockManager: double free or
corruption (fasttop): 0x000000001b4d4dc0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x310d8722ef]
/lib64/libc.so.6(cfree+0x4b)[0x310d87273b]
stasis-read-only/build/src/stasis/libstasis.so[0x2ae4d5571841]
stasis-read-only/build/src/stasis/libstasis.so[0x2ae4d5571c72]
stasis-read-only/build/src/stasis/libstasis.so(lhinsert+0x16f [0x2ae4d55720cc]
stasis-read-only/build/src/stasis/libstasis.so(pblHtInsert+0x84)[0x2ae4d557247f]
stasis-read-only/build/src/stasis/libstasis.so(createLock+0x94)[0x2ae4d557cdad]
stasis-read-only/build/src/stasis/libstasis.so(lockManagerReadLockHashed+0x10c)[
0x2ae4d557cf11]
stasis-read-only/build/src/stasis/libstasis.so(lockManagerReadLockRecord+0x1c)[0
x2ae4d557d66c]
stasis-read-only/build/test/stasis/check_lockManager(ridWorkerThread+0xc2)[0x401
95b]
/lib64/libpthread.so.0[0x310e4064a7]
/lib64/libc.so.6(clone+0x6d)[0x310d8d3c2d]
======= Memory map: ========
*** glibc detected ***
stasis-read-only/build/test/stasis/check_lockManager: double free or
corruption (!prev): 0x000000001b4ee420 ***
======= Backtrace: =========
***Exception: Other

What version of the product are you using? On what operating system?

RHEL5 2.6.18-164, GLIBC 2.5

Please provide any additional information below.

passed all other test cases

Original issue reported on code.google.com by kwon.yon...@gmail.com on 9 Sep 2009 at 10:42

[GoogleCodeExporter]

Thanks for the bug report!  However, the lock manager is just a proof of 
concept that
will probably eventually be removed.  Note that a number of other unit tests
currently fail non-deterministically.  Check 
http://tardis.cs.berkeley.edu/flamebox
for a list.

It looks like this regression is due to r1243, which disables mutex locking 
inside of
the in-memory hashtables.

Original comment by sears.ru...@gmail.com on 9 Sep 2009 at 11:41

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Fixed by adding a lockManager-specific threadsafe wrapper around the pbl 
wrappers. 
This approach uses a single, global mutex, which is far from ideal.  The lock 
manager
should probably be refactored, and should use transaction table commit handlers
instead of the hard-coded logic currently sprinkled throughout stasis.

Original comment by sears.ru...@gmail.com on 23 Jan 2010 at 2:33

• Changed state: Verified