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

David Holmes david.holmes at oracle.com
Sun Mar 8 23:40:55 UTC 2015

Hi Thomas,

Minor nit: in src/share/vm/runtime/stubRoutines.cpp::test_safefetchN can 
you use UCONST64 macro instead of explicit ULL - thanks.

Otherwise this seems okay, but we will also need the aarch64 component 
(and I'll look into our internal needs).


On 7/03/2015 2:10 AM, Thomas Stüfe wrote:
> 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