This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/24443] New: Locking recursive mutex puts it into incorrect state with static linking
- From: "hubertpel at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 10 Apr 2019 18:03:08 +0000
- Subject: [Bug nptl/24443] New: Locking recursive mutex puts it into incorrect state with static linking
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=24443
Bug ID: 24443
Summary: Locking recursive mutex puts it into incorrect state
with static linking
Product: glibc
Version: 2.27
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: nptl
Assignee: unassigned at sourceware dot org
Reporter: hubertpel at gmail dot com
CC: drepper.fsp at gmail dot com
Target Milestone: ---
Compiling following program with static linking causes assert to fail.
#include <pthread.h>
#include <cassert>
int main()
{
pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
pthread_mutex_lock(&recmutex);
pthread_mutex_unlock(&recmutex);
assert(pthread_mutex_destroy(&recmutex) == 0);
}
using:
g++ mutex_test.cpp -o test -static -lpthread
with dynamic linking above program works fine.
The problem is that
pthread_mutex_lock.c:97 : pid_t id = THREAD_GETMEM (THREAD_SELF, tid);
function THREAD_GETMEM (THREAD_SELF, tid) returns 0 when mutex's owner is also
initialized as 0 causing it to pass
pthread_mutex_lock.c:100 : if (mutex->__data.__owner == id)
and in addition not go into:
pthread_mutex_lock.c:159 : ++mutex->__data.__nusers;
so, when pthread_mutex_unlock goes into:
pthread_mutex_unlock.c:49 : if (decr)
pthread_mutex_unlock.c:51 : --mutex->__data.__nusers;
it decrements __nusers to 0xffffffff.
which causes problem while destroying mutex later on.
Bug is present on ubuntu 18 with libc-2.27, gcc-7.3.0
--
You are receiving this mail because:
You are on the CC list for the bug.