Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: running the following small program from a commandline (winXP) - it returns after 3 seconds the same program started in eclipse blocks on System.in.close() public class HangOnClose implements Runnable { public HangOnClose() { super(); } public void run() { System.out .print("waiting in System.in.read() for System.in to be closed> "); System.out.flush(); try { System.out.println((char) System.in.read()); } catch (final IOException e) { e.printStackTrace(); } } public static void main(final String[] args) throws InterruptedException, IOException { new Thread(new HangOnClose()).start(); System.out.println("wait 3 seconds"); Thread.sleep(3000); System.out.println("closing input: System.in.close()"); System.in.close(); System.out.println("input closed"); } } More information:
Moving to JDT/Debug
The problem is that in Eclipse our proxy IOConsoleInputStream is waiting for input that it will never get. We should break out of waiting if the underlying input stream is closed before input is received. Once in the waiting state in the console if you press the enter key, you will get an IOException, because System.in has been closed but the IOConsoleInputStream does not think so. Partial dump showing IOConsoleInputStream waiting once System.in has been closed: "Worker-3" prio=6 tid=0x57344c00 nid=0x4c4 in Object.wait() [0x5850f000..0x5850f a14] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x07a567a8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185) - locked <0x07a567a8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:21 7) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51) "Worker-2" prio=6 tid=0x57439400 nid=0xaa0 in Object.wait() [0x5840f000..0x5840f a94] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0a408068> (a org.eclipse.ui.console.IOConsoleInputStream ) at java.lang.Object.wait(Object.java:485) at org.eclipse.ui.console.IOConsoleInputStream.waitForData(IOConsoleInpu tStream.java:147) at org.eclipse.ui.console.IOConsoleInputStream.read(IOConsoleInputStream .java:92) - locked <0x0a408068> (a org.eclipse.ui.console.IOConsoleInputStream) at org.eclipse.ui.console.IOConsoleInputStream.read(IOConsoleInputStream .java:117) at org.eclipse.debug.internal.ui.views.console.ProcessConsole$InputReadJ ob.run(ProcessConsole.java:679) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "Worker-1" prio=6 tid=0x5737ec00 nid=0xa94 in Object.wait() [0x5830f000..0x5830f b14] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x07a567a8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185) - locked <0x07a567a8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:21 7) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51)
further inspection revealed this to be a dupe of bug 40066, with a work-around provided in the sun bug report referenced in comment 14. *** This bug has been marked as a duplicate of bug 40066 ***
I don't think this problem is related to a native library - more that you have the same problem as Java's BufferedReader: close() is synchronized (in BufferedReader on the lock-Object, in eclipse IOConsoleInputStream the method itself. That means it is a synchronize-lock situation.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
