Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Sep 2004 15:59:22 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: easy to reproduce unkillable threads
Message-ID:  <41589B4A.9080508@elischer.org>
In-Reply-To: <16728.37731.540143.307772@grasshopper.cs.duke.edu>
References:  <16728.37731.540143.307772@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help


Andrew Gallatin wrote:

>I've put together a quick and dirty example of the thread
>deadlock-on-exit (sometimes lingering thread) problem I've been
>seeing with my driver and FreeBSD threads.  See the long "Re:
>Unkillable KSE threaded proc" thread from earlier this month for
>details. 
>
>The tarball linked below is based on /usr/share/examples/kld/cdev
>To reproduce the problem, build the module and load it.
>Then build testcdev, and run it.  
>
>Install the skill-4.1.1 port.  Then ssh in from another host, and do 'skill
>-9 -u $USER'.  
>



>This should leave you with a stuck thread..
>

hmm looks like the problem is that the condition variable respods to a 
masked signal


the signals are all masked from the perspective of the thread..the 
signal is delivered to the signal
catcher thread so the UTS can handle it but in the meanwhile the thread 
has done a RESTART..

 David: check out what happens when a signal is delivered to a worker 
thread that is in a cv_wait_signal()

>
>> .
>>
>
> I haven't checked it as yet but I am starting to see some hint of some 
> problem..
> The fact that cv_wait_signal()  reacts to a blocked signal surproses me..
> (according to teh man page)
>
>http://people.freebsd.org/~gallatin/threadlock.tgz
>
>
>I would really love for somebody to look at it before 5.3-R...
>
>Thank you,
>
>
>Drew
>  
>



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