Bug 917810

*** Bug 917811 has been marked as a duplicate of this bug. ***

Could you attach the core dump or the output of "thr bt a a"?

(gdb) thread apply all bt

Thread 4 (Thread 0x7f18ef881700 (LWP 5832)):
#0  0x00007f18ef46305f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f18ef8b27a3 in st_queue_handler (arg=<optimized out>) at state.c:1120
#2  0x00007f18ef45f0a4 in start_thread () from /lib64/libpthread.so.0
#3  0x00007f18ee2cb7fd in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f18ef892700 (LWP 5831)):
#0  0x00007f18ef463408 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f18ef8bd709 in alarm_handler (arg=<optimized out>) at alarm.c:190
#2  0x00007f18ef45f0a4 in start_thread () from /lib64/libpthread.so.0
#3  0x00007f18ee2cb7fd in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f18ef85b800 (LWP 5830)):
#0  0x00007f18ef4604c2 in pthread_join () from /lib64/libpthread.so.0
#1  0x00007f18ef8c1b16 in master_done (master=0x7f18efef7780) at master.c:1705
#2  0x00007f18ef8a38ff in statemachine (arg=0x0) at automount.c:1443
#3  main (argc=0, argv=<optimized out>) at automount.c:2419

Thread 1 (Thread 0x7f18e7993700 (LWP 5838)):
#0  0x00007f18ef4681b8 in __lll_unlock_elision () from /lib64/libpthread.so.0
#1  0x00007f18ef8befdd in master_mutex_unlock () at master.c:57
#2  0x00007f18ef8a5b7c in handle_mounts_cleanup (arg=0x7f18eff4f620) at automount.c:1606
#3  0x00007f18ef8a6505 in handle_mounts (arg=0x7fffa9930a00) at automount.c:1792
#4  0x00007f18ef45f0a4 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f18ee2cb7fd in clone () from /lib64/libc.so.6

It's trying to unlock a mutex that's not locked. pthread_mutex_unlock() returns error and automount aborts.

Unlocking an unlocked mutex has either "undefined behavior" or "error returned" according to the man page.

Looks like in most systems, "undefined behavior" translates to "return success". The code below works fine on my machine (kernel-desktop-3.18.3-1.3.x86_64, glibc-2.20-2.2.x86_64), on 11-SP3 (kernel-default-3.0.101-0.46.1, glibc-2.11.3-17.80.3) but segfaults on oldboy (kernel-default-3.14.0-2.2.x86_64,
glibc-2.19-19.1.x86_64).

#include <pthread.h>

int main(void)
{
	pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

	pthread_mutex_lock(&mutex);
	pthread_mutex_unlock(&mutex);
	return pthread_mutex_unlock(&mutex);
}

Andreas, do you remember if the behavior changed sometime ago?

Trying to unlock a mutex of type NORMAL that isn't locked has always been undefined.  If you want error checking you need to use an ERRORCHECK type.

See <http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_unlock.html>.

When I run the code from comment #4 on my machine (glibc-2.20-2.2.x86_64), after pthread_mutex_lock():

> (gdb) p/x mutex
> $2 = {__data = {__lock = 0x1, __count = 0x0, __owner = 0xedf, __nusers = 0x1, __kind = 0x0, __spins = 0x0, 
>     __elision = 0x0, __list = {__prev = 0x0, __next = 0x0}}, __size = {0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xdf, 
>     0xe, 0x0, 0x0, 0x1, 0x0 <repeats 27 times>}, __align = 0x1}

The same on Dirk's machine (glibc-2.19-19.1.x86_64):

> (gdb) p/x mutex
> $1 = {__data = {__lock = 0x1, __count = 0x0, __owner = 0x0, __nusers = 0x0, __kind = 0x100, __spins = 0x0,
>      __elision = 0x3, __list = {__prev = 0x0, __next = 0x0}}, __size = {0x1, 0x0 <repeats 16 times>, 0x1, 0x0, 0x0,
>      0x0, 0x0, 0x3, 0x0 <repeats 17 times>}, __align = 0x1}

How do I tell glibc to use lock elision? Dirk, perhaps you still have those workarounds to run Groupwise and they're getting on the way?

Assuming this was fixed somehow.