This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17208] New: pthread_cond_wait may put mutex into incorrect state if mutex has elision disabled
- From: "robert at ocallahan dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 28 Jul 2014 06:41:38 +0000
- Subject: [Bug nptl/17208] New: pthread_cond_wait may put mutex into incorrect state if mutex has elision disabled
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17208
Bug ID: 17208
Summary: pthread_cond_wait may put mutex into incorrect state
if mutex has elision disabled
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
Assignee: unassigned at sourceware dot org
Reporter: robert at ocallahan dot org
CC: drepper.fsp at gmail dot com
pthread_cond_wait calls __pthread_mutex_cond_lock_adjust after acquiring the
mutex's futex. __pthread_mutex_cond_lock_adjust has the following code:
if (mutex->__data.__kind == PTHREAD_MUTEX_PI_RECURSIVE_NP)
++mutex->__data.__count;
I think this code should check PTHREAD_MUTEX_TYPE(mutex->__data.__kind).
Otherwise, if the mutex is recursive but __kind has the
PTHREAD_MUTEX_ELISION_NP or PTHREAD_MUTEX_NO_ELISION_NP, __count will not be
incremented and a later pthread_mutex_unlock of the mutex goes wrong,
decrementing __count from 0 to 0xffffffff and failing to unlock the mutex.
--
You are receiving this mail because:
You are on the CC list for the bug.