RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling

Thomas Stüfe thomas.stuefe at gmail.com
Fri Mar 6 16:10:42 UTC 2015


Hi all,

could someone please review the following fix (I also will need a sponsor):

http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.01/

https://bugs.openjdk.java.net/browse/JDK-8074552

The fix will make SafeFetch[32,N] work in error reporting.

At SAP, we use SafeFetch a lot in error reporting to poke around in
potentially invalid memory (e.g. writing hex dumps over areas which may be
partly unmapped), and we feel that this could be useful for the OpenJDK too.

Without this fix, SafeFetch will cause a crash, the current error reporting
step will be interrupted and error reporting will continue with the next
step; that is not optimal because the interrupted step may have shown
valuable information.

This fix handles SafeFetch faults during error reporting the same way as
they are handled normally. The changes are:

- handle safe fetch fault in the various (os_cpu dependend) secondary
signal handlers

- provide a function to check if it is safe to use SafeFetch:
CanUseSafeFetch32(). SafeFetch needs stub routines and will crash when used
before stub generation.

- set_context_pc() is added which complements the existing get_context_pc()
and all instances where the pc in ucontext_t was modified directly are
changed to use set_context_pc()

- in stubRoutines.cpp, a small test was added to the already existing stub
routines tests which run at VM init

- in vmError.cpp, a test was added to test SafeFetch during error
reporting, similar to the tests introduced for 8065895

- A JTreg test was added

Thanks and Kind Regards,

Thomas Stuefe


More information about the hotspot-runtime-dev mailing list