Reading subprocess stdout susceptible to deadlock
vitalyd at gmail.com
Wed Mar 30 14:45:56 UTC 2016
The stack traces are:
"process reaper" #44 daemon prio=10 os_prio=0 tid=0x0000000004083000
nid=0x7b1c waiting for monitor entry [0x00002b703ffbe000]
java.lang.Thread.State: BLOCKED (on object monitor)
- waiting to lock <0x00000000aba7a790> (a
at java.lang.UNIXProcess$$Lambda$10/523574157.run(Unknown Source)
"pool-1-thread-1" #43 prio=5 os_prio=0 tid=0x0000000003ee3800
nid=0x7b13 runnable [0x00002b7050837000]
at java.io.FileInputStream.readBytes(Native Method)
- locked <0x00000000aba7a790> (a
SomeClass.callReadOnInputStream() is something that invokes
InputStream.read(byte, int, int) on the stream.
On Wed, Mar 30, 2016 at 10:09 AM, Roger Riggs <Roger.Riggs at oracle.com>
> Hi Vitaly,
> I haven't seen that before, please create a bug and include the stack
> Thanks, Roger
> On 3/30/2016 9:56 AM, Vitaly Davidovich wrote:
>> It seems that doing a blocking read on a subprocess's stdout can lead to
>> deadlock between the thread doing the read and the process reaper thread.
>> The deadlock occurs because the reader is synchronized on the
>> ProcessPipeInputStream, blocks for more data to consume, and process
>> comes along trying to call processExited, which also synchronizes on the
>> same PPIS. The reader appears stuck because it's not seeing the EOF due
>> process reaper not being able to close the stream.
>> I couldn't find any existing reports of this via quick search, which makes
>> me wonder if I'm missing something. Is this a known issue?
More information about the core-libs-dev