This is the mail archive of the
mailing list for the glibc project.
Re: pthread_mutex_destroy returns EBUSY, but the mutex isn't locked
- From: "Adrian Ludwin" <adrian dot ludwin at gmail dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: libc-help at sourceware dot org
- Date: Wed, 4 Jun 2008 13:36:13 -0400
- Subject: Re: pthread_mutex_destroy returns EBUSY, but the mutex isn't locked
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=r5SXpKVLARl3KKSd2tridqNyDVguETyxy3FdZc7Fs4g=; b=oXLKLktTzfopQ0hwtIR17H6ux0rrLYIjg1mJfumn/WWTrvD6B2tOwFDA9mBLaCGrVX EmetmjD0VwOr8aqat7AzNXk6YuRDrnIM+lhW5huPab8HS1+EZExpYWHXWJxoWhoFX5h4 sJGcV8OT1/5kwdSJSS/AEuEtdUImWyOiPgFm8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=JO7ppk+r9arMLDwDgrgXLqug9gRZSiZoB0xOajY51WdM2s8iVGw/M6mZJPBCzXHpu1 tPTDTCtYmI2wWMn4r02qX1hmPS8MX4kgjIxd8ZVq1MbtY7474D0Feim+umhTP1XxPS8p InREOaua2qTYxmyMMmzr1NTlsyjzbuLHegOP0=
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- Reply-to: adrian dot ludwin at gmail dot com
> Can you reproduce this using glibc cvs head?
> It could be a glibc or kernel bug.
I'm using a fairly old glibc (2.3.4) and I can't even reproduce this
on a different release of the same version of that library, so I
haven't tried reproducing on a completely different one.
Have glibc/kernel bugs been common/reported in this part of the
library? (I tried to look through bugzilla but I'm not sure if it
would have covered everything, or just stuff reported by end users).
I'd be extremely surprised if mutexes were broken in any significant
way, given how fundamental they are to so any multithreaded
algorithms. The only way I could imagine this escaping notice for a
while is if people aren't checking their return values from
pthread_mutex_destroy - does anyone find this likely?