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.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 >