From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10983 invoked by alias); 29 Dec 2008 12:26:01 -0000 Received: (qmail 9821 invoked by uid 48); 29 Dec 2008 12:24:45 -0000 Date: Mon, 29 Dec 2008 12:26:00 -0000 From: "billmason_sp2 at yahoo dot com" To: glibc-bugs@sources.redhat.com Message-ID: <20081229122444.9691.billmason_sp2@yahoo.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug nptl/9691] New: pthread race condition causes tst-mutex8 to fail X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00117.txt.bz2 tst-mutex8 usually runs fine but occasionally (~10% of the time) fails with this error: cl: mutex_unlocked failed So I tried adding print statements to tst-mutex8.c, pthread_mutex_lock.c, and pthread_mutex_unlock.c to trace them, and I'm pretty sure there is a race condition. It only happens for recursive locks. check_type creates the thread and calls pthread_barrier_wait. tf (the thread) locks the mutex, and calls pthread_barrier_wait. create_type then does an extra lock and unlock, then cancels the thread. Meanwhile, tf has added cl to its cleanup, and is in pthread_cond_wait, which unlocks the mutex at the beginning and locks it at the end. But before the lock happens, the thread has been canceled, and cl is called, which calls unlock again, after nusers is already 0. It returns EPERM and tst-mutex8 fails. The way to replicate the problem is to run tst-mutex8, but I presume plenty of developers have done this already. It's a race condition, which makes it very difficult to replicate. Hopefully it can be replicated by running it a few hundred times in a loop. Otherwise, I hope you can check the code to see if I'm correct that there is a race condition. I might be missing something, as I'm not familiar with this code, but it looks like a race condition from the few hours of debugging I did. Here are the details of the system that has produced this problem: glibc-2.8-20081222 i686-pc-linux-gnu Options to configure: --prefix=/usr --disable-profile --enable-add-ons --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc configparms: CFLAGS += -march=i486 -mtune=native I'm experiencing this while trying to build Linux From Scratch 6.4: http://www.linuxfromscratch.org/lfs/view/stable/chapter06/glibc.html Host system: Debian etch Kernel: 2.6.18-6-686 #1 SMP Fri Dec 12 16:48:28 UTC 2008 i686 GNU/Linux GCC version: 4.3.2 GNU ld version: 2.18 -- Summary: pthread race condition causes tst-mutex8 to fail Product: glibc Version: 2.8 Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: drepper at redhat dot com ReportedBy: billmason_sp2 at yahoo dot com CC: billmason_sp2 at yahoo dot com,glibc-bugs at sources dot redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=9691 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.