-
Bug
-
Resolution: Incomplete
-
P4
-
None
-
21
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
A deadlock may occur with Process and reading it's input stream.
How ProcessImpl works:
* waits for the process to finish
* sets hasExited and fires condition
* launches processExited on PipeInputStream
PipeInputStream has two synchronization on it's processExited function. Second one is lock on closeLock object. And the first one synchronizes on it's own instance. PipeInputStream does not use InternalLock for syncrhnizations cause it's a subclass of BufferedInputStream. It means that all calls to 'read' will be synchronized on the same instance.
Usually we want to read all input data until the end of the process. But with current implementation, input stream pipe is not closed automatically. It mean if we'll be reading input stream from one thread we can stuck in the 'read' function when no more input data is available. And we will be stuch with lock acquired. As a result processExited function will be also stuck (deadlock) waiting for us to release this lock. But it will be never released, cause noone will close the input stream and there will be no more any input.
CUSTOMER SUBMITTED WORKAROUND :
As a workaround we can read input stream in separate thread and wait for ('waitFor') in the 'main' thread. And we can close inputstream as soon as waitFor will complete. Probably this may result in an incomplete data from input stream in some situations, but this will unblock 'read' call in case no more data available to read.
FREQUENCY : occasionally
A deadlock may occur with Process and reading it's input stream.
How ProcessImpl works:
* waits for the process to finish
* sets hasExited and fires condition
* launches processExited on PipeInputStream
PipeInputStream has two synchronization on it's processExited function. Second one is lock on closeLock object. And the first one synchronizes on it's own instance. PipeInputStream does not use InternalLock for syncrhnizations cause it's a subclass of BufferedInputStream. It means that all calls to 'read' will be synchronized on the same instance.
Usually we want to read all input data until the end of the process. But with current implementation, input stream pipe is not closed automatically. It mean if we'll be reading input stream from one thread we can stuck in the 'read' function when no more input data is available. And we will be stuch with lock acquired. As a result processExited function will be also stuck (deadlock) waiting for us to release this lock. But it will be never released, cause noone will close the input stream and there will be no more any input.
CUSTOMER SUBMITTED WORKAROUND :
As a workaround we can read input stream in separate thread and wait for ('waitFor') in the 'main' thread. And we can close inputstream as soon as waitFor will complete. Probably this may result in an incomplete data from input stream in some situations, but this will unblock 'read' call in case no more data available to read.
FREQUENCY : occasionally