https://bugs.openldap.org/show_bug.cgi?id=9278
--- Comment #5 from Xin Li delphij@freebsd.org --- (In reply to Howard Chu from comment #4)
(In reply to Xin Li from comment #3)
Created attachment 738 [details] Proposed patch
Oops, yes you are right and I clearly have some misunderstanding of the code here, sorry for the noise.
Here is a different proposal, basically, it would destroy the robust mutex if we are the only remaining user. My understanding of https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02. html#tag_15_09_09 was that the effect after unmapping of the mutex object is undefined, on FreeBSD, it seems to confuse the threading library because after the last mmap is gone, the kernel GC's the object, while it's still on userland threading library's bookkeeping ( https://svnweb.freebsd.org/base/head/lib/libthr/thread/thr_pshared. c?annotate=297141#l220 ) if they are not destroyed.
Last time I checked, FreeBSD didn't even support robust process shared mutexes. What OS revision is required for this to be supported?
The support of robust mutexes was added in FreeBSD r300043 (May 17, 2016) and is supported by all currently supported FreeBSD releases (11.3, 11.4 and 12.1). The first release with robust mutex support was FreeBSD 11.0-RELEASE (October 2016).
It seems to me that doing what this test program is doing is a misuse of the API, you should only ever open an environment once in any particular process. Closing it and then opening it again makes no sense.
Without cleaning up the mutex before unmapping, lmdb will leave the recorded mutex behind and the current code will not be able to recover from that (unlike in the case the calling process crashed, the code would correctly recover from the situation). Since lmdb is performing similar cleanups for semaphores, destroying the mutexes when we are the last user of the database seems to be the right thing to do in my opinion.