RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552
sgehwolf at redhat.com
Mon Mar 23 13:02:05 UTC 2015
Updated webrev which does what you suggested:
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.
> The current implementation of SafeFetch on Zero can not provide this
> functionality so in my eyes it is useless.
> 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
> The test changes are good.
> 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
More information about the hotspot-runtime-dev