This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: pthread_mutex_destroy returns EBUSY, but the mutex isn't locked
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: adrian dot ludwin at gmail dot com
- Cc: libc-help at sourceware dot org
- Date: Wed, 4 Jun 2008 12:13:21 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=DEA3X9mApOyDzqo+ziNvIq/nkhM4QyDpM4ewGb8B7eA=; b=TLejVlGByFClD6so5g4G+ohWtqc2Q9tcRPO94N95qlL2te7VPdfoPhRw/PIRvZ5xej oRdTWIm3xizeiOk0QQcjLIqHOFxs/sgZo5nGrAEJKIeirx69WJDnHU/qXpQ7RJUmLkzw V1YXK7GMSMPbl/SGz+Ub03qKFIhu6mVDOyYP0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=l4tA1/DkAyGoe/ox0fFazF5u2D+8uo0gkBHQKbdF+jf8bC61rnoEMtvSRT5srvARte hL3K60N5ANkuVYEM/eW1G0D2CZiuGqSTqZ5DNUl2LdXDcrrNYc1XTPdYdQKZNXRQMwbq fEu3RC1kpvf+iW989S8sZZ8Q9tYr2UxvPDZJc=
- References: <58fe92790806040548r10e09333x971047764992ca4e@mail.gmail.com> <119aab440806040711v7162178ex6c10204a4573b547@mail.gmail.com> <58fe92790806040715o395e9901od355d1bdabcc48c2@mail.gmail.com>
On Wed, Jun 4, 2008 at 10:15 AM, Adrian Ludwin <adrian.ludwin@gmail.com> wrote:
> Thanks, but that seems unlikely for a reason I forgot to mention: all
> threads except the main thread have been successfully joined *before*
> I attempt to destroy any of the mutexes. In addition, I never create
> more than three additional threads for this algorithm (I'm running on
> a quad-core machine and the main thread remains active) and I'm
> occasionally seeing nusers go as high as 10.
Can you reproduce this using glibc cvs head?
It could be a glibc or kernel bug.
Cheers,
Carlos.