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

David Holmes david.holmes at oracle.com
Tue Jul 9 21:56:29 PDT 2013


On 9/07/2013 10:37 PM, Peter Allwin wrote:
> Hi David,
>
> I changed the is_init_trigger's max path to be consistent within the file.
> This was probably an oversight when is_init_trigger was introduced as all
> other paths in attachListener_(linux|bsd) use UNIX_PATH_MAX. I'm not sure
> which limit is correct. Should I revert those lines?

Given the way the temp directory is hard-wired to /tmp it will not make 
a practical difference here as we will be well within both limits - but 
otherwise this change could have caused a failure if the full path was > 
108 characters.

The two limits are for different things. We only need to use 
UNIX_PATH_MAX when the path will be linked to a socket. For regular 
filesystem paths it is PATH_MAX that counts.

I'd prefer to see it reverted.

Thanks,
David

>
> Thanks!
>
> /peter
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Tuesday, July 9, 2013 1:47 PM
> To: Peter Allwin
> Cc: serviceability-dev at openjdk.java.net;
> hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file
> number during HotSpotVirtualMachine.executeCommand
>
> Hi Peter,
>
> Why did you change from using PATH_MAX+1 to UNIX_PATH_MAX in
> is_init_trigger? AFAICS the .attach_pid file is not linked to a socket and
> so not limited to UNIX_PATH_MAX.
>
> David
>
> On 8/07/2013 11:54 PM, Peter Allwin wrote:
>> Hello!
>>
>> Looking for reviews of this change:
>>
>> http://cr.openjdk.java.net/~allwin/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
>>
>


More information about the hotspot-runtime-dev mailing list