Created attachment 10743 [details]
ide.log

Petr, could I ask you for your advice about what could be wrong here? 

OK, this is very ugly one and it seems it shouldn't happen, but I
think I've found how it can occur:
IIRC, we're using Thread.stop() to kill some internal things,
probably also for stopping internal tomcat (Jirka?)

The IMSE can occur if you do monitorexit on already unlocked monitor.
The bytecodes for the method are:
...
21 monitorenter
...
95 monitorexit
96 ireturn
...
144 monitorexit 
Ex table:
from:22 to:96 use:141 type:any

That means:
if the method just executed the bytecode 95 (i.e. unlocked the
monitor) and the Thrad.stop() is called on it exactly at that time,
the ThreadDeathError exception is invoked in that thread and the
control is forwarded to offset 141, where it tries to unlock the same
monitor again.

Now, this is my hypothesis based on assumption that we're using
Thread.stop() and that bytecode execution can really be interrupted
between those two bytecodes.
If this is the real thing happening inside VM, this exception should
be very rare and also innocent (just kills the thread that was going
to be killed anyway).
If the problem is reproducible (or not that rare), please note it.

I'll try to ask JDK/VM team for more details, but using of
Thread.stop() is strongly discouraged and deprecated for a long time
already ...

Thanx very much Petr!

The same exception was reported in issue 31682 which I closed as
worksforme, because I was not able to reproduce it.

I also tend to think that this exception should be harmless. Do you
think I should catch it and log it just as INFORMATIONAL warning?
Because otherwise I do not see much else I could do here.

Created attachment 11665 [details]
ide.log

Sorry, wrong issue - ignore C:\projects\kuk\ide.log

Sorry for a late reply to Petr N's question - I overlooked this.

Well, I think Thread.stop() is used internally by the execution
framework (method org.netbeans.core.execution.DefaultSysProcess.stop()
calls ThreadGroup.stop()), but I don't see why it should really be
needed to stop Tomcat. Tomcat only needs to kill the external Tomcat
process, and then the threads which copy the standard output of the
external process to the IDE's output window. But I don't think we need
to use Thread.stop() for this. 

So I think the question is whether we can rearchitect the internals of
the execution framework in such a way that it does not use a thread
that is then stop()-ed. I don't understand why the internal thread is
there - can you enlighten me please? Thanks.

I don't understand much of the execution framework but I have noticed
too many threads as well:
1. The ThreadExecutor which waits for ThreadGroup to finish
  2. The ProcessExecutor which spawns the external process and waits
    for the result
  3.-5. CopyMaker threads which forward stdin/stdout/stderr between
    the process and IO window
6. JDK's process reaper thread (only one per running JVM?)

(1) is IMO not really needed.
I hope (3)-(5) can be merged using nio on JDK1.4
 

"...too many threads..." -> adding Jesse to CC:

You do need Thread.stop() for some cases, e.g. when using internal
execution and it just keeps on going and you wish to kill it. For
stopping an external process, or for well-behaved internal processes,
it should not be necessary. We could probably clean up the engine to
only use T.s() when actually necessary. ExecutorTask already has a
stop() method which IMHO is all the engine should need to call -
ThreadExecutor should implement this with Thread.stop().

*** Issue 36577 has been marked as a duplicate of this issue. ***

changing owner dkonecny -> pnejedly

OK, I've worked around the exception (which could occur for internal
execution even if we improve the framework).
The rest is a RFE about threading in execution framework.

Reassigning to new module owner Tomas Holy.

Probably long obsolete.