the only remaining user.
When closing an lmdb database, all memory and file descriptor resources
are released, including the shared memory pages that contained the
robust mutex.
However, before this commit, prior to unmapping the pages that contained
the robust mutexex, lmdb did not destroy the mutexes first. This would
create a problem when an application opens and closes a database, then
open it again.
According to libthr(3), by default, a shared lock backed by a mapped
file in memory is automatically destroyed on the last unmap of the
corresponding file' page, which is allowed by POSIX.
After unmapping the shared pages, the kernel writes off all active
robust mutexes associated with these pages. However, the userland
threading library still keeps the record (pshared_lookup in
thr_pshared.c of libthr) for these objects as they are not really
destroyed before, so that it don't have to ask the kernel every
time when looking them up.
Now, a later re-open of the database might have mapped the lock file
to the same memory location. Because the threading library have
remembered the robust mutex object, it would just reuse it even though
it was already invalid from kernel's point of view. Unfortunately,
regular lock operations would still work for this process.
Should another lmdb process opens the same database, it would attempt
to obtain the robust mutex (no longer recognized by kernel) because it
would see another process holding a file lock, but that would fail
because the robust mutex is invalid for the kernel.
Explicitly destroy the mutex if we are the last remaining user to ensure
the mutex is always in a known defined state.
OpenLDAP ITS #9278
With debugging help from: kib
PR: 244493
MFH: 2020Q2
6c3f69c928