RFR: JDK-8322163: runtime/Unsafe/InternalErrorTest.java fails on Alpine after JDK-8320886

[Martin Doerr]

On Thu, 21 Dec 2023 09:12:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We notice failures/crashes on Alpine Linux, maybe after [JDK-8320886](https://bugs.openjdk.org/browse/JDK-8320886).
> test runtime/Unsafe/InternalErrorTest.java crashes on Alpine (works fine on other test OS/CPU platforms) :
> 
> 
> #
> # SIGSEGV (0xb) at pc=0x00007fd3c080064f, pid=7075, tid=7161
> #
> # JRE version: OpenJDK Runtime Environment (23.0) (build 23-internal-adhoc.jenkinsi.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (23-internal-adhoc.jenkinsi.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # C [ld-musl-x86_64.so.1+0x5464f] memset+0xa7
> #
> 
> 
> Looks like the Alpine memset triggers unexpected SIGSEGV  (not the expected SIGBUS).  So we switch to a loop instead of memset.    However I noticed that on Linux aarch64  the test starts to fail when the loop is used instead of the memset, so I keep the old coding on this platform .

I think it's very bad to let C code run into signals (SIGBUS or SIGSEGV). In addition, the signal handler just skips the faulting instruction and continues with the next one. That does not yield defined behavior!
(On linux aarch64, the new loop doesn't work, because gcc generates an strb instruction with internal address increment. The signal prevents both, the store and the address increment, so we end up in an endless loop.)
If we only want to do a simple fix for Alpine x86_64, I suggest to use the new code only on that platform. It's bad for other platforms, too, but it works because it gets tested. (Doesn't mean that it will always work with every compiler. So, there's still room for improvement.)

-------------

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17175#pullrequestreview-1793264095