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

[Dmitry Samersoff]

David,

Yes, UNIX_PATH_MAX is a historic constant that limit size of sun_path in
sockaddr_un.

But I would support Peter - on my opinion it's better to always use the
same constant.

And (being paranoid) it's better to check return value of snprintf to
make sure we are getting correct file name to unlink.

-Dmitry


On 2013-07-10 08:56, David Holmes wrote:
> 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
>>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.