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

[Peter Allwin]

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?


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
>