Debugging segmentation faults in the JVM on linux-powerpc

[John Paul Adrian Glaubitz]

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

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 [1].

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 @@
   test_arraycopy_func(CAST_FROM_FN_PTR(address, Copy::aligned_conjoint_words), sizeof(jlong));
   test_arraycopy_func(CAST_FROM_FN_PTR(address, 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();
-#endif
-
 #endif
 }

But it still segfaults. Are there other places where safefetch*() needs to be disabled?

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

Thanks!
Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-9&arch=powerpc&ver=9%7Eb170-2&stamp=1497177935&raw=0

-- 
 .''`.  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