RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552

[Severin Gehwolf]

On Fri, 2015-03-20 at 16:34 -0400, Coleen Phillimore wrote:
> Severin,  Thank you for taking care of this.   I have one question for 
> the greater project.
> 
> Is there platform support in jtreg so we don't need to change the Java code?
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html
> 
> +    if (!Platform.isDebugBuild() || Platform.isZero()) {

I'm not sure I understand the question. Could you elaborate? What's
"platform support in jtreg" exactly?

FWIW, I'm not aware of any specific Zero support in jtreg itself.

Cheers,
Severin

> Thanks,
> Coleen
> 
> On 3/20/15, 1:45 PM, Severin Gehwolf wrote:
> > Hi Volker,
> >
> > Thanks for the review!
> >
> > On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote:
> >> Hi Severin,
> >>
> >> I can't understand how SafeFetch32 and SafeFetchN are supposed to work
> >> at all in Zero. The whole point of having the SafeFetch routines is to
> >> have a possibility of peeking at potentially illegal memory addresses.
> > You are right. I did some digging in the hg history and it seems this
> > implementation for Zero has been added with JDK-8022188 after
> > JDK-8016697 introduced it.
> >
> >> The current implementation of SafeFetch on Zero can not provide this
> >> functionality so in my eyes it is useless.
> > I agree.
> >
> >> I think we should do the following:
> >>   - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero
> >> (this way the unmodified CanUseSafeFetchXX() routines would work for
> >> Zero as well)
> >>   - remove the implementations of  SafeFetchN and SafeFetch32 and set
> >> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry
> >> to NULL in stubGenerator_zero.cpp (this will automatically make
> >> StubRoutines::SafeFetchN_stub() return null on Zero)
> >>   - the calls to test_safefetch32XX() should be guarded by
> >> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in
> >> stubRoutines.cpp)
> > Sounds good, I'll follow up with an updated webrev shortly.
> >
> >> The test changes are good.
> > Cheers,
> > Severin
> >
> >> Regards,
> >> Volker
> >>
> >>
> >> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> >>> Hi,
> >>>
> >>> Could somebody please review and sponsor this patch?
> >>>
> >>> The commit of JDK-8074552 broke the Zero port since it performs tests on
> >>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers
> >>> (relying on a continuation scheme for safe fetch errors) work. Yet
> >>> performing this test correctly requires support from the signal handler
> >>> and access routines to ucontext_t which are missing for Zero.
> >>>
> >>> The intent of JDK-8074552 was to improve error reporting on SEGV's.
> >>> Having this feature in Zero is less useful, since it's a C++ interpreter
> >>> only environment.
> >>>
> >>> This patch disables the test and makes CanUseSafeFetch* functions return
> >>> false unconditionally for Zero JVMs so as to not produce a recursive
> >>> SEGV's during error reporting.
> >>>
> >>> I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped
> >>> for Zero.
> >>>
> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533
> >>> webrev:
> >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/
> >>>
> >>> Testing done: make bootcycle-images fails before this patch and passes
> >>> after for a Zero JVM on x86_64.
> >>>
> >>> Thanks,
> >>> Severin
> >>>
> >
> >
>