Marcos-David Dione/NCE/AMADEUS wrote on 24/11/2014 11:10:42: > Seen like that I'm not sure if there's a defined behaviour > for that. I'll ask in the glibc and/or kernel MLs and I'll come > back with the answer. and here's the answer: > On 11/24/2014 03:34 PM, Marcos Dione wrote: > > We found a situation where a robust mutex cannot be recovered > > from a stale lock and we're wondering if it's simply an undefined > > situation or a bug in the kernel. Attached you will find the sample > > code, which is loosely based on a glibc's test case.The gist of it is as > > follows: > > > > 1. we open a file. > > 2. we mmap it and use that mem to store a robust mutex. > > 3. we lock the mutex. > > 4. we munmap the file. > > 5. we close the file. > > Undefined behaviour. > > This results in undefined behaviour since the allocated storage for > the mutex object has been lost. You need to keep that storage around > for the robust algorithms to work with. Without any data you can't > do anything. Full answer: https://sourceware.org/ml/libc-help/2014-11/msg00035.html

"openldap-devel" <openldap-devel-bounces(a)openldap.org&gt; wrote on 25/11/2014 16:19:40: > Fyi, this would not have been a bug in Solaris: > > https://docs.oracle.com/cd/E19253-01/816-5168/pthread-mutexattr- > setrobust-np-3c/index.html you mean, because of the phrase «When the owner of a mutex with the PTHREAD_MUTEX_ROBUST_NP /robustness/ attribute dies, or when the process containing such a locked mutex unmaps the memory containing the mutex or performs one of the _exec(2)_ <https://docs.oracle.com/docs/cd/E19253-01/816-5167/exec-2/index.html>f..., the mutex is unlocked.»? I'm not sure that when it says 'unmap' it means 'munmap()s'.