RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand

[David Holmes]

On 22/08/2012 9:52 PM, Alan Bateman wrote:
> On 22/08/2012 02:26, David Holmes wrote:
>>
>> I was going to make a similar request. Some context for the problem
>> and solution makes reviewing a lot easier.
>>
>> In this case as I understand it between checking the fd for the door
>> call and making the door call, someone can call detach, and so we get
>> EBADF. The detach is synchronized on this, so the fix moves the
>> enqueue inside the sync block so that it has to complete before anyone
>> can call detach.
> The detach method is specified so that the behavior for this case is
> implementation-specific so Dmitriy's change is okay, it's just that I
> assume the detach will block indefinitely in the event that the target
> VM does not respond to a command. With a bit of work then I think we can
> change this code to support asynchronous detach, probably using the
> usual dup2 trick that we do elsewhere in the libraries. The question is
> whether it's worth doing as the scenario is only likely to arise with
> tests, not the simple command-line tools. So I think the proposed change
> is okay for now, we should just make sure to submit an RFE to remember
> to re-visit this again in the future.

Ah I see. I'm not familiar with the details of the underlying 
communication protocol. If the enqueue can indeed block indefinitely 
then moving it inside the sync block prevents the detach indefinitely. 
In which case the enqueue needs to remain an "open call" but the native 
method needs to be robust in the face of EBADF and/or the calling code 
needs to handle that possibility when there is a race with the detach.

David
-----


> -Alan