JDK-6938627 : Make temporary directory use property java.io.tmpdir when specified
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs14,hs18,5.0,6,6u24
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,solaris_2.5.1
  • CPU: generic,x86,sparc
  • Submitted: 2010-03-26
  • Updated: 2017-10-22
  • Resolved: 2010-04-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs18Fixed
Related Reports
Duplicate :  
JDK-6900754 - JDK searches for PerfDataFile in adifferent location from where the VM creates i
Duplicate :  
JDK-6447182 - temp dir locations should not be hardcoded for hsperfdata_ dirctories
Duplicate :  
JDK-7023338 - jps command not showing other jvms running under the callers user context
Relates :  
JDK-7014520 - java/awt/FontClass/CreateFont/DeleteFont.sh test passes just in a second invocation against jdk7b125
Relates :  
JDK-8189674 - -Djava.io.tmpdir doesn't work for generating hs_error files
Relates :  
JDK-6944822 - Fix for 6938627 exposes problem with hard-coded buffer sizes
Relates :  
JDK-6950927 - Testcase failure sun/management/jmxremote/bootstrap/JvmstatCountersTest.java
Relates :  
JDK-6649594 - Intermittent IOExceptions during dynamic attach on linux and solaris
Relates :  
JDK-7009828 - Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined
Description
The directory "/tmp" or %TEMP% on windows is hardcoded in the JVM and should be changed to look at the property java.io.tmpdir first.
Comments
This fix had a number of flow on effects due to buffer size assumptions that had been made in various parts of the code - 6944822 caught some of those. In addition this fix exposed a buffer overflow bug in the Linux attachListener code. That code contained the following: 165 int LinuxAttachListener::init() { 166 char path[PATH_MAX+1]; // socket file ... 194 if (res == -1) { 195 sprintf(path, "%s/.java_pid%d", os::get_temp_directory(), os::current_process_id()); 196 strcpy(addr.sun_path, path); When get_temp_directory() always returned /tmp the path length was constrained to being very short, but once the tmpdir property is used the path can be up to PATH_MAX bytes long. The problem is that addr.sun_path is only UNIX_PATH_MAX bytes long: 108. Hence we can overwrite other values on the stack and crash the VM. This was seen on the SE-Embedded ARM implementations. I suspect it was not seen elsewhere because the above code only executes if an initial bind attempt fails - or it may simply be that tmpdir was still short enough. The original code should have been using strncpy to limit the length of the path copied - which in turn might have made the author realise there was a potential problem with the different buffer sizes. Curiously the comment in the original code: 166 char path[PATH_MAX+1]; // socket file makes me wonder if the author had known of this issue and inadvertently used PATH_MAX instead of UNIX_PATH_MAX. In any case this bug was actually fixed as part of: 6649594: Intermittent IOExceptions during dynamic attach on linux and solaris by restricting the path to UNIX_PATH_MAX length in the first place.
22-10-2017
EVALUATION Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either.
01-04-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a2ea687fdc7c
01-04-2010