JDK-8130910 : hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_ has wrong permissions
- Type: Bug
- Component: hotspot
- Sub-Component: svc
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2015-07-10
- Updated: 2016-04-27
- Resolved: 2015-08-20
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.
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 8 | JDK 9 |
|---|---|
8u101Fixed  |
9 b81Fixed |
Description
The JDK on Unix/Linux platforms will create a shared memory file for performance data, named like the process pid, in /tmp/hsperfdata_<username> directory. If that directory has wrong permissions, that is, no execute permissions (e.g. mod bits 644), the performance file will be created in the current working directory. Usually the file will be deleted when the VM ends. But in this case it will remain. One can easily reproduce it by either deleting /tmp/hsperfdata_<username> and running a Java program with umask 133 or by first doing a chmod 644 on /tmp/hsperfdata_<username> and then running a java program. After the program has finished, a new file, named like a number, will exist in the cwd. The problem can be easily fixed by checking the return value of the fchdir() call in open_directory_secure_cwd().
Comments
|