RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand

[serguei.spitsyn at oracle.com]

Peter,

I've added the label "noreg-hard" with the comment to the report.
It is not easy to reproduce the issue and demonstrate the fix in a 
regression test.

Thanks,
Serguei


On 7/8/13 11:36 AM, serguei.spitsyn at oracle.com wrote:
> Hi Peter,
>
> The fix looks good.
>
> Thanks,
> Serguei
>
> On 7/8/13 6:54 AM, Peter Allwin wrote:
>>
>> Hello!
>>
>> Looking for reviews of this change:
>>
>> http://cr.openjdk.java.net/~allwin/7162400/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eallwin/7162400/webrev.01/>
>>
>> For CR:
>>
>> http://bugs.sun.com/view_bug.do?bug_id=7162400
>>
>> https://jbs.oracle.com/bugs/browse/JDK-7162400
>>
>> Summary:
>>
>> This change addresses an issue in the Attach API on Solaris, Linux 
>> and BSD where an attaching application can receive IOExceptions such 
>> as "Bad file number" (Solaris), "Connection refused" (Linux/BSD), or 
>> "well-known file is not secure".
>>
>> The attach process uses a file in the temporary directory as a door 
>> (Solaris) or domain socket (Linux,BSD) to communicate with the VM. In 
>> certain circumstances stale files can be left in the file system 
>> which can cause the attaching application to believe that the VM is 
>> ready to receive a connection when it's not. With this change the 
>> stale file will be removed during VM startup.
>>
>> Note that there is still an issue if we don't have permission to 
>> remove the stale file, the attaching process will fail to connect.
>>
>> Testing:
>>
>> JPRT, reproducing script on Solaris, Linux.
>>
>> Credits:
>>
>> Thanks to Staffan Larsen who worked on this issue with me.
>>
>> Regards,
>>
>> Peter
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130708/9e000b5a/attachment.html