[11u] RFR: 8257828 SafeFetch may crash if invoked in non-JavaThreads

Thomas Stüfe thomas.stuefe at gmail.com
Fri Apr 23 12:11:51 UTC 2021


Hi,

may I please have reviews for this backport, which fixes crashes which can
happen if SafeFetch is used from within non-java-threads.

Issue: https://bugs.openjdk.java.net/browse/JDK-8257828

Original patch: https://git.openjdk.java.net/jdk/commit/3ab1dfeb

Unfortunately the original patch does not apply at all, since we unified
all the coding in JDK16 to os_posix.cpp. Which is a change I do not want to
backport.

So the 11u specific patch looks big but is actually simple:

- for all Posix platforms, in all the various signal handlers, we heave the
handling of SafeFetch faults out of the "if current thread is java thread"
condition up some lines, and do it unconditionally. Exception are the SAP
platforms (AIX, linux ppc and s390) where we had fixed this bug already, so
nothing to do here

- for Windows, no such change was necessary, but there was a bug where
Handle_Exception() did cast Thread to JavaThread without checking. The
change here looks bigger than necessary to keep the code similar to
upstream.

- the new gtest is mostly unchanged from the upstream version apart from a
fixed include (safefetch.hpp -> stubroutines.hpp) and the definition
of invalid_address, since VMError::segfault_address is missing from JDK 11.

11u Patch:
http://cr.openjdk.java.net/~stuefe/webrevs/backports/8257828-safefetch-non-java-threads

Testing: full gamut of SAP tests ran tonight seemingly ok, but I will rerun
due to the current instability of 11u. However this patch touches two
platforms we don't test (solaris x86, arm 32bit), so I would be happy if
someone with access to those platforms could test at least the build, and
if possible run the gtests too.

Thanks, Thomas


More information about the jdk-updates-dev mailing list