Community
Participate
Working Groups
When I build an Autotools Project and create an a.out executable, whenever I run it via right-clicking on it and "Run as a C/C++ executable", the executable runs successfully, but I get the following error logged: Error logged from Debug Core: java.io.IOException: read error at org.eclipse.cdt.utils.spawner.SpawnerInputStream.read0(Native Method) at org.eclipse.cdt.utils.spawner.SpawnerInputStream.read(SpawnerInputStream.java:66) at java.io.BufferedInputStream.read1(BufferedInputStream.java:273) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.eclipse.debug.internal.core.OutputStreamMonitor.read(OutputStreamMonitor.java:144) at org.eclipse.debug.internal.core.OutputStreamMonitor.access$1(OutputStreamMonitor.java:134) at org.eclipse.debug.internal.core.OutputStreamMonitor$1.run(OutputStreamMonitor.java:207) at java.lang.Thread.run(Thread.java:636) This happens all the time for an Autotools executable. I chose gdb/mi when given the choice on the execution.
It is probably harmless. You app probably exists faster than steam monitor can read anything... It app hello world like? Does it print anything on console?
On 06/01/2010 08:34 AM, James Blackburn wrote: > Taking a look at this debug.core OutputStreamMonitor does: > > try { > ... > fStream.read(...); > ... > } catch (IOException e) { > if (!fKilled) { > DebugPlugin.log(ioe); > } > return; > } > > So it seems the exception shouldn't be logged during tear down. But > fKilled ins't volatile (and there isn't any synchronisation) so that's > likely part of the problem...
Hmm. Digging just a little bit deeper, OutputStreamMonitor#fKilled only becomes true on StreamsProxy#kill() [called by RuntimeProcess#terminate()]. This never seems to be called, so this seems to be logged every time...
This looks like a duplicate of your other bug Jeff. *** This bug has been marked as a duplicate of bug 286162 ***
Created attachment 185245 [details] Proposed fix. When the error is received, the stream monitor is already supposedly closed (fThread == null). I think the fix is to simply add a test for whether the monitor is closed already. This behavior is already implemented for handling an NPE. I looked in the history of this module to see if there's a special reason why the IOException is handled differently than NPE, but I don't see anything. This behavior dates back to '02 and handling for the NPE was added much later.
