Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 315259

Summary: Error logged in Debug Core when running C/C++ executable
Product: [Eclipse Project] Platform Reporter: Jeff Johnston <jjohnstn>
Component: DebugAssignee: Platform-Debug-Inbox <platform-debug-inbox>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: elaskavaia.cdt, jamesblackburn+eclipse, pawel.1.piech
Version: 3.6   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Proposed fix. none

Description Jeff Johnston CLA 2010-06-01 13:28:07 EDT 
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.
Comment 1 Elena Laskavaia CLA 2010-06-01 13:32:03 EDT 
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?
Comment 2 Pawel Piech CLA 2010-06-01 14:05:19 EDT 
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...
Comment 3 James Blackburn CLA 2010-06-01 14:24:22 EDT 
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...
Comment 4 James Blackburn CLA 2010-12-15 06:06:26 EST 
This looks like a duplicate of your other bug Jeff.

*** This bug has been marked as a duplicate of bug 286162 ***
Comment 5 Pawel Piech CLA 2010-12-15 12:30:33 EST 
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.