This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
040722, 1.5.0 b58. Don't know if it's reproducible.
Created attachment 16400 [details] Stack trace
Dupe, but would be nice to get logging on it. Is it possible for some kind of buffering/threading to alter the ordering, so that halting the process could close the stream while some other thread is still collecting output, and tries to send it after the stream's been closed? I'd imagine whatever writes output is not on the AWT thread, but halting the process probably is - when you halt a process, does it immediately try to close the output stream, or just kill the process and let it get around to closing it somehow? *** This issue has been marked as a duplicate of 44143 ***
The End Process command just sends a Thread.stop(). I think the Ant module tries to close its streams in a finally block which should be run under such conditions. In this particular stack trace, ZipFile.close is resulting in a debug message being printed, due to a patch I have installed to log closed files. However this is coming synchronously within the body of a task, so that is not in itself anything weird. Maybe most of the stack trace is running inside a finally block, but this should still be all inside the finally block of the Ant module that closes the stream, so I can offer no explanation of how this happens. Anyway, is this relevant? Surely the output window should know whether its stream is closed or not. At least such an exception should be just printed to console, not result in an exception dialog.
closed