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

[Thomas Stüfe]

Hi David,

I am sorry, but I am unable to reproduce the error. Both slowdebug and
fastdebug builds on Windows come up and SafeFetch works (also in error
handling). Are you sure the crash is caused by my change? If yes, could you
send me an hs-err file or at least the configure line you used for building?

Kind Regards, Thomas

On Mon, Mar 9, 2015 at 7:51 AM, David Holmes <david.holmes at oracle.com>
wrote:

> 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
>>
>>
>>