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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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