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

[David Holmes]

On 9/03/2015 4:21 PM, Thomas Stüfe wrote:
> Hi David,
>
> Ouch. The only thing I can think about are the added initialization
> tests in stubRoutines.cpp. I will check this.

Ah! It hadn't registered with me that this test code was going to be 
executed. Seems the likely cause as a clean repo has no problems.

David

> Kind Regards, Thomas
>
>
>
> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     FYI When I applied this to latest hs-rt forest and ran through JPRT
>     the Windows fastdebug builds were DOA (instant segfault just running
>     "java -version"). Can't see how your changes could do this so
>     running a test on unmodified forest.
>
>     David
>
>
>     On 9/03/2015 9:40 AM, David Holmes wrote:
>
>         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).
>
>         Thanks,
>         David
>
>         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/
>             <http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.01/>
>
>             https://bugs.openjdk.java.net/__browse/JDK-8074552
>             <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
>
>