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.hol...@oracle.com]
Sent: Tuesday, July 9, 2013 1:47 PM
To: Peter Allwin
Cc: serviceability-dev@openjdk.java.net;
hotspot-runtime-...@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
