-
Bug
-
Resolution: Unresolved
-
Major
-
None
If for various reasons a thread that "owns" one end of the pipe aborts unexpectedly, the other end can block forever, and the thread dump doesn't tell anything about why it's blocking.
The worst failure mode of this bug is when the channel reader thread deadlocks because of this, as it performs I/O synchronously. In this case the channel eventually fails, yet Hudson won't even notice that it failed.
java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:474) hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:136) hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:115) hudson.remoting.ProxyOutputStream$Chunk.execute(ProxyOutputStream.java:164) hudson.remoting.Channel$ReaderThread.run(Channel.java:863)
Several ideas to help diagnose this problem:
- stream pair should refer to each other via a weak reference, so that if the other end is abandoned we'd be able to tell.
- allow optional name to be set on the pipe so that thread name can be changed while blocking.