This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17514] New: Assert failure unlocking ERRORCHECK mutex after timedlock (related to lock elision)
- From: "juhapi+sw at lubenter dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 27 Oct 2014 11:04:51 +0000
- Subject: [Bug nptl/17514] New: Assert failure unlocking ERRORCHECK mutex after timedlock (related to lock elision)
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17514
Bug ID: 17514
Summary: Assert failure unlocking ERRORCHECK mutex after
timedlock (related to lock elision)
Product: glibc
Version: 2.20
Status: NEW
Severity: critical
Priority: P2
Component: nptl
Assignee: unassigned at sourceware dot org
Reporter: juhapi+sw at lubenter dot net
CC: drepper.fsp at gmail dot com
I noticed an application crashing in pthread_mutex_unlock(), and simplified the
problematic call sequence to the one seen in this simple program:
#include <pthread.h>
int main()
{
pthread_mutex_t m;
pthread_mutexattr_t attr;
struct timespec abs_time = {0};
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
pthread_mutex_init(&m, &attr);
pthread_mutex_timedlock(&m, &abs_time);
pthread_mutex_unlock(&m); // <= assert fails here
return 0;
}
If the mutex is of default type, or if locking is done with
pthread_mutex_lock(), the assert doesn't fail. Also I believe the problem only
occurs when lock elision is available. But the combination of ERRORCHECK mutex,
pthread_mutex_timelock() and lock elision seems problematic.
The bactrace I get is below. The assert fails because m.__data.__kind is 258
(=0x102, with the elision bit 0x100 set) but the pthread_mutex_unlock() expects
it to be 2. I don't know if the problem is in pthread_mutex_timedlock() that
sets the elision bit, or in pthread_mutex_unlock() that doesn't allow the bit
to be set.
(gdb) bt
#0 0x00007fe5eebb6a07 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007fe5eebb7dda in __GI_abort () at abort.c:89
#2 0x00007fe5eebaf8bd in __assert_fail_base (fmt=0x7fe5eecebab8 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7fe5eef38530 "type ==
PTHREAD_MUTEX_ERRORCHECK_NP", file=file@entry=0x7fe5eef38518
"pthread_mutex_unlock.c", line=line@entry=87,
function=function@entry=0x7fe5eef38560 <__PRETTY_FUNCTION__.7552>
"__pthread_mutex_unlock_usercnt") at assert.c:92
#3 0x00007fe5eebaf972 in __GI___assert_fail
(assertion=assertion@entry=0x7fe5eef38530 "type ==
PTHREAD_MUTEX_ERRORCHECK_NP",
file=file@entry=0x7fe5eef38518 "pthread_mutex_unlock.c",
line=line@entry=87, function=function@entry=0x7fe5eef38560
<__PRETTY_FUNCTION__.7552> "__pthread_mutex_unlock_usercnt")
at assert.c:101
#4 0x00007fe5eef30efe in __pthread_mutex_unlock_usercnt (mutex=<optimized
out>, decr=<optimized out>) at pthread_mutex_unlock.c:87
#5 0x000000000040085c in main () at glibc_bug_mutextest.c:14
--
You are receiving this mail because:
You are on the CC list for the bug.