RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17)

[Howard Chu]

Content preview: 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? [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: highlandsun.com]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

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.