Volker Lendecke wrote:

On Wed, Nov 11, 2015 at 09:49:49AM +0000, Howard Chu wrote:

...

Volker Lendecke wrote:

...

On Wed, Nov 11, 2015 at 12:09:51AM +0000, Howard Chu wrote:

...

Unfortunately, PTHREAD_MUTEX_ROBUST_NP is an enum, not a macro, so #ifdef won't work to detect it.

The attached patch should work. Please report back; I won't merge it unless we know it actually helps.

Not sure you're aware, but there's RHEL5 (and thus Centos5 I believe) versions where glibc announces robust mutexes but the kernel is buggy: They are just not robust. tdb has a runtime check for this. Are you interested?

Sure, post a link to more info.

I found this since you mentioned it.

https://bugzilla.redhat.com/show_bug.cgi?id=628608

But it only affects a mutex that was locked in a process that subsequently forks a child. The LMDB docs already say explicitly that a process must not fork with an open LMDB environment so this particular issue doesn't affect us.

Nope, this was properly ordered. Fork, then lock, then exit, and the subsequent locker did not get EOWNERDEAD. Not sure about the exact behavior anymore though.

https://git.samba.org/?p=samba.git;a=blob;f=lib/tdb/common/mutex.c;h=fae43d4...

has the tdb_runtime_check_for_robust_mutexes that verifies we're in a sane environment.

Thanks. I still see your test doing a fork after init'ing the mutex. That's the condition that triggered the above bug - not the timing of the actual mutex_lock. This was fixed in June 2011, glibc 2.15. And as before, it doesn't affect LMDB.