I've answered this before:

	- Threads SEGV after the kill(otherthread, RT0) inside the
	  sighandler.
	- After that, threads spin and are killable only with -KILL.
	- I suspect that the problem is with the way we are setting
	  up the signal frame.
	- I have not had time to work on this yet.

christos

In article <200212022125.gB2LPFi12742@plucky.openg.ilx.com>,
Paul J. Lavoie <pjl@ilx.com> wrote:
>
>This has come up a few times with no one seemingly giving an answer, so
>I thought I'd bring it up again, and see if anyone has any ideas. The
>problem is that 
>under certain intensive java applications run under a JIT/native
>version of the java interpreter, one of the threads will run away with
>the CPU, and require a 
>'kill -9' in order to recover.
>
>While taking a look at some of the applications that I have that
>exhibit this trait, what I have notices is that the more intensive the
>program, the quicker 
>that this problem will exhibit itself. Some applications take hours to
>reach this state, others are immediate. In addition, the thread
>(process) that does run 
>away with the CPU seems to be immune to having 'ktruss' decipher
>anything about it. This leads me to believe that something in the
>kernel is having a fit, and 
>it is not simply a misemulated system call.
>
>I have some java apps that I would like to run native on NetBSD and not
>resort to remote displays from more functional systems. Any help or
>suggestions are 
>welcome.
>
>Thanks.
>
>-------------------------------------------------------------------------------
>Paul J. Lavoie		paul.lavoie@tfn.com	(212) 510-3029
>Sales, Trading and Wealth Management		111 Fulton Street, 2nd Floor
>Thomson Financial				New York, NY  10038
>
>