Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Jan 2008 14:31:33 -0800
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        Gary Stanley <gary@velocity-servers.net>, Julian Elischer <julian@elischer.org>, freebsd-threads@freebsd.org
Subject:   Re: threads/119920: fork broken in libpthread
Message-ID:  <20080124223133.GU99258@elvis.mu.org>
In-Reply-To: <Pine.GSO.4.64.0801241732070.16957@sea.ntplx.net>
References:  <200801240850.m0O8o2JQ023500@freefall.freebsd.org> <4798564B.7070500@elischer.org> <20080124222339.GT99258@elvis.mu.org> <Pine.GSO.4.64.0801241732070.16957@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Daniel Eischen <deischen@freebsd.org> [080124 14:28] wrote:
> On Thu, 24 Jan 2008, Alfred Perlstein wrote:
> 
> >* Julian Elischer <julian@elischer.org> [080124 01:17] wrote:
> >>Gary Stanley wrote:
> >>>The following reply was made to PR threads/119920; it has been noted by
> >>>GNATS.
> >>>
> >>>From: Gary Stanley <gary@velocity-servers.net>
> >>>To: bug-followup@FreeBSD.org
> >>>Cc:
> >>>Subject: Re: threads/119920: fork broken in libpthread
> >>>Date: Thu, 24 Jan 2008 03:24:47 -0500
> >>>
> >>>I also have this problem, see threads/118715
> >>>
> >>>I was able to grab some ktrace info, but most of the time the process
> >>>is stuck, and ktrace doesn't display any data.
> >>>
> >>>_______________________________________________
> >>>freebsd-threads@freebsd.org mailing list
> >>>http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> >>>To unsubscribe, send any mail to 
> >>>"freebsd-threads-unsubscribe@freebsd.org"
> >>
> >>dan what IS the fix for this?  I assume you must have fixed it in
> >>-current/7
> >>
> >>what was YOUR fix alfred?
> >
> >Attached.
> 
> Which isn't a correct fix, BTW.  It is possible that the unlock
> can try to give the lock to a non-existent thread.

Yes, I understand that problem, but it's not clear to my why/how it can happen.

I guess because another thread could put itself on the "blocked queue"
for that lock?  Is there a way to prevent that or to clear the lock
afterward?

-Alfred



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080124223133.GU99258>