Debugging segmentation faults in the JVM on linux-powerpc
thomas.stuefe at gmail.com
Sun Jun 11 18:58:11 UTC 2017
On Sun, Jun 11, 2017 at 12:53 PM, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:
> Hi Thomas!
> On 06/11/2017 08:45 AM, Thomas Stüfe wrote:
> > I'll take a look at it, I believe the final SafeFetch implementation for
> zero was last done by me: https://bugs.openjdk.java.net/browse/JDK-8076185
> Thanks. I'm very glad to hear that someone more knowledgeable with the
> code will have a look.
> > SafeFetch is used to load data from a potentially unmapped address,
> mainly used in error reporting. If that load triggers a segfault, that
> fault is catched and
> > the function returns a special value to indicate the address was
> Yeah. I have learned that now as well ;).
> > Its function is in the debug build tested at VM startup, which is the
> segfault you are seeing. If it were to work correctly, signal handler would
> recognize the
> > segfault to be originating from a safefetch call and not crash but
> return the mentioned special value.
> > On almost all platforms this is implemented via stub assembler but as
> zero aims to be pure C we did implement this using posix setjmp. I'll take
> a look at why
> > this stopped working.
> > In the meantime, as a workaround just comment out the calls to
> test_safefetch32() and test_safefetchN() in StubRoutines::initialize2().
> That doesn't seem to work though, it still crashes .
> I made this change:
> --- a/hotspot/src/share/vm/runtime/stubRoutines.cpp~ 2017-05-11
> 15:11:42.000000000 +0300
> +++ b/hotspot/src/share/vm/runtime/stubRoutines.cpp 2017-06-11
> 12:25:56.068000000 +0300
> @@ -358,13 +358,6 @@
> Copy::aligned_conjoint_words), sizeof(jlong));
> Copy::aligned_disjoint_words), sizeof(jlong));
> - // test safefetch routines
> - // Not on Windows 32bit until 8074860 is fixed
> -#if ! (defined(_WIN32) && defined(_M_IX86))
> - test_safefetch32();
> - test_safefetchN();
> But it still segfaults. Are there other places where safefetch*() needs to
> be disabled?
Sorry, I was wrong, the workaround cannot work. SafeFetch is required to
work in a number of other places, so there is no easy way around fixing
this. I also am very curious as to why we crash, the SafeFetch mechanism on
Zero is quite simple.
> Please note:
> I cannot reproduce the problem on x86_64 which made me believe to think
> that there might
> be some code guarded out on x86_64 which is only used on the generic zero
Unfortunately, I ran into a number of issues building zero on ppc and x64,
which is quite annoying. Zero gets not enough love :) Finally managed to
build it on x64, but as you said, SafeFetch works fine here.
I was not able to build it on ppc64 (the only ppc machines I have
available). Will retry next week. Without reproducing this error, it is
difficult to fix.
Note that I have no ppc32 (big endian?) machine available.
If you feel like investigating yourself, feel free. The mechanism for
safefetch on zero is quite simple, see the patch for JDK-8076185:
Basically, before the questionable memory access a jump buffer is set up
and its pointer is stored in pthread TLS; which then is recovered in the
signal handler. Its existence is taken as proof that the SIGSEGV was caused
by SafeFetch; and we use longjmp to jump back to before the crash. Simple
and unexciting :)
Kind Regards, Thomas
> >  https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
More information about the hotspot-dev