JDK-8257828 : SafeFetch may crash if invoked in non-JavaThreads
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-12-07
  • Updated: 2021-05-20
  • Resolved: 2020-12-15
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 11 JDK 17
11.0.12Fixed 17 b02Fixed
Related Reports
Relates :  
Relates :  
Description
In our primary hotspot signal handlers, SafeFetch handling is limited to JavaThread objects:

```
  JavaThread* thread = NULL;
...
  if(t->is_Java_thread()) {
    thread = (JavaThread*)t;
  }
...
  if (info != NULL && uc != NULL && thread != NULL) {
    pc = (address) os::Linux::ucontext_get_pc(uc);
    if (StubRoutines::is_safefetch_fault(pc)) {
```

As a result of this, using SafeFetch may crash non-JavaThreads if the location is invalid. E.g. using SafeFetch inside a VMOperation may crash the VM.

This is unfortunate since SafeFetch is used for os::is_readable_pointer() which explicitly promises to not crash. It is used e.g. in os::print_hex_dump(). There is also no reason why SafeFetch would not work for non-JavaThreads. In fact, SafeFetch handling for the secondary signal handler works just fine for all threads.

This is an old bug, unrelated to the recent Posix cleanups. AFAICS it has been there at least since Jdk11.
Comments
Fix Request (11u): I'd like to fix this since this error may cause crashes in non-java threads if SafeFetch is used. Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb Does not apply at all, since we unified a lot of the POSIX coding in jdk16. So this is a complete new development, from scratch. The fix itself is rather primitive, for details see RFR thread: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-May/006119.html 11u patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads Testing: Tests at SAP ran several weeks in a row
19-05-2021

Changeset: 3ab1dfeb Author: Thomas Stuefe <stuefe@openjdk.org> Date: 2020-12-15 07:00:54 +0000 URL: https://git.openjdk.java.net/jdk/commit/3ab1dfeb
15-12-2020

ILW = MLM = P4
08-12-2020

AFAICS this is day one code for the safe-fetch facility. It seems to have come into Java 6 with a backport to 5. The safefetch handling was always within the check for a non-null JavaThread. I expect the original use of safefetch was only possible from a JavaThread.
08-12-2020

Looks like I already fixed this for our platforms ages ago; so ppc and s390 are not affected by this.
08-12-2020