Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.3
-
None
-
None
-
Oracle JDK 1.8.0_72 x64 on MS Windows 10 Pro x64
Description
I encountered a serious glitch when using commons-exec 1.3 with Java 8 - something that didn't happen with previous Java versions (tested with Java 5 and 7).
In order to feed a process' normal input stream, commons-exec uses Process.getOutputStream() - which is normally a BufferedOutputStream, wrapping a FileOutputStream, pointing to the OS's pseudo-file connected to the process' normal input stream.
In Java 8, the process might terminate with the BufferedOutputStream still having unwritten bytes in its buffer, while the underlying FileOutputStream gets automatically closed.
DefaultExecutor always tries to close all of the process' streams, in closeProcessStreams() - but because the process' BufferedOutputStream still has bytes in its buffers (count > 0), it first tries to flush it to the underlying FileOutputStreams, throwing an IOException (Stream closed).
The following scenario reproduces the problem:
- Use DefaultExecutor to start a process which does not expect (or read) any bytes from the normal input stream.
- Feed the process (using PumpStreamHandler) a large amount of bytes.
- Execute
The change in behavior between Java 8 and previous versions actually lies within FilterOutputStream, which contains the implementation of close() used by BufferOutputStream - before Java 8, the implementation would ignore (swallow) any exception cause by the call to flush() in close() - in Java 8, the exception propagates.
Attachments
Attachments
Issue Links
- is related to
-
EXEC-102 "Stream closed" error in Java 8 when passing input to processes that don't consume it
- Open