Reading subprocess stdout susceptible to deadlock

Roger Riggs Roger.Riggs at Oracle.com
Mon Jan 23 16:05:50 UTC 2017


Hi Vitaly,

There probably is something that can be done to avoid the deadlock.
ProcessExited may need to use a different lock.
Please file an issue.

Roger




On 1/20/2017 5:14 PM, Vitaly Davidovich wrote:
> Hi all,
>
> Just wanted to revisit this issue again.  I haven't filed a JBS entry 
> for it, primarily because I'd like some validation/confirmation/hunch 
> that this is, indeed, a bug before proceeding.  Does anyone have 
> thoughts on this scenario?
>
> Thanks
>
> On Wed, Mar 30, 2016 at 10:45 AM, Vitaly Davidovich <vitalyd at gmail.com 
> <mailto:vitalyd at gmail.com>> wrote:
>
>     Hi Roger,
>
>     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)
>
>              at java.lang.UNIXProcess$ProcessPipeInputStream.processExited(UNIXProcess.java:528)
>
>              - waiting to lock <0x00000000aba7a790> (a java.lang.UNIXProcess$ProcessPipeInputStream)
>
>              at java.lang.UNIXProcess.lambda$initStreams$275(UNIXProcess.java:299)
>
>              at java.lang.UNIXProcess$$Lambda$10/523574157.run(Unknown Source)
>
>              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>       
>
>       
>
>     "pool-1-thread-1" #43 prio=5 os_prio=0 tid=0x0000000003ee3800 nid=0x7b13 runnable [0x00002b7050837000]
>
>         java.lang.Thread.State: RUNNABLE
>
>              at java.io.FileInputStream.readBytes(Native Method)
>
>              at java.io.FileInputStream.read(FileInputStream.java:255)
>
>              at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
>
>              at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
>
>              at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
>
>              - locked <0x00000000aba7a790> (a java.lang.UNIXProcess$ProcessPipeInputStream)
>
>             at SomeClass.callReadOnInputStream()
>     SomeClass.callReadOnInputStream() is something that invokes
>     InputStream.read(byte[], int, int) on the stream.
>     Thanks
>     On Wed, Mar 30, 2016 at 10:09 AM, Roger Riggs
>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>
>         Hi Vitaly, I haven't seen that before, please create a bug and
>         include the stack traces. Thanks, Roger
>         On 3/30/2016 9:56 AM, Vitaly Davidovich wrote:
>
>             Hi, 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 reaper 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 to 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? Thanks 
>


More information about the core-libs-dev mailing list