JDK-8254661 : arm32: additional cleanup after fixing SIGSEGV
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: arm
  • Submitted: 2020-10-13
  • Updated: 2024-12-13
  • Resolved: 2020-11-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b24Fixed
Related Reports
Relates :  
JDK-8253901 - ARM32: SIGSEGV during monitorexit due to incorrect register use (after JDK-8253540)
Description
http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-October/044500.html
> since JDK-8253540 has been applied to master (77a0f3999afa322b64643afd4a161164440af975) JDK builds on arm32 fail for me, even after the corresponding fix JDK-8253901. The newly built JVM crashes right after the start with SIGSEGV.
Comments
Changeset: 362feaae Author: Boris Ulasevich <bulasevich@openjdk.org> Date: 2020-11-11 11:09:26 +0000 URL: https://github.com/openjdk/jdk/commit/362feaae
11-11-2020
Hi Nick, you are right. Some comments to clear things up. Original JDK-8253901 issue was introduced in [1] and fixed in [2]. This issue was reported about RaspberryPi build fail (cross-compilation ARM32 build worked OK) - it was introduced by the change [3] and fixed by [4]. The only remaining problem now is fastdebug build fail (all ARM32, not RPi only). This is my pull request to address the problem: https://bugs.openjdk.java.net/browse/JDK-8253901 thanks, Boris [1] commit 77a0f3999afa322b64643afd4a161164440af975 Author: Coleen Phillimore <coleenp at openjdk.org> Date: Mon Sep 28 15:49:02 2020 +0000 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [2] commit fd0cb98ed03c6214c02ccd3503c1e6d77065a428 Author: Boris Ulasevich <bulasevich at openjdk.org> Date: Thu Oct 8 06:52:27 2020 +0000 8253901: ARM32: SIGSEGV during monitorexit due to incorrect register use (after JDK-8253540) [3] commit ea27a54bf0ff526effb47f9daaec51ced2d2bb71 Author: Calvin Cheung <ccheung at openjdk.org> Date: Mon Oct 5 16:52:00 2020 +0000 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms [4] commit 5145bed0282575a580cf3ebc343038c1dc8ddb8d Author: Ioi Lam <iklam at openjdk.org> Date: Fri Oct 16 05:14:46 2020 +0000 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows
11-11-2020
Hi Boris, are you still planning to work on this? I think the change below will fix the assertion failure. As you say, Rresult is unused and we know Rlock == R0 always. diff --git a/src/hotspot/cpu/arm/interp_masm_arm.cpp b/src/hotspot/cpu/arm/interp_masm_arm.cpp index a819c0fa8486..7f5aec99b804 100644 --- a/src/hotspot/cpu/arm/interp_masm_arm.cpp +++ b/src/hotspot/cpu/arm/interp_masm_arm.cpp @@ -996,8 +996,7 @@ void InterpreterMacroAssembler::unlock_object(Register Rlock) { const Register Robj = R2; const Register Rmark = R3; - const Register Rresult = R0; - assert_different_registers(Robj, Rmark, Rlock, R0, Rtemp); + assert_different_registers(Robj, Rmark, Rlock, Rtemp); const int obj_offset = BasicObjectLock::obj_offset_in_bytes(); const int lock_offset = BasicObjectLock::lock_offset_in_bytes ();
09-11-2020
Current status: 1) arm32 release builds are now green, probably after commit 5145bed0282575a580cf3ebc343038c1dc8ddb8d. 2) fastdebug build still fails with the above assertion.
29-10-2020
@Boris On my raspberry Pis 4 the build fails after 20min. I can do builds for you or if you give me e.g. a Github URL I can quickly set up a CI job for you.
15-10-2020
1. I have reproduced the crash on RPi. To reproduce it I need run "make images", not just "make". 2. Crash reproduced on support/interim-image jdk (same time the command with build/linux-arm-server-release/jdk works Ok): $ /home/pi/boris/jdk/build/linux-arm-server-release/support/interim-image/bin/java \ -XX:DumpLoadedClassList=/home/pi/boris/jdk/build/linux-arm-server-release/support/link_opt/classlist.raw.2 \ -XX:SharedClassListFile=/home/pi/boris/jdk/build/linux-arm-server-release/support/link_opt/classlist.interim \ -XX:SharedArchiveFile=/home/pi/boris/jdk/build/linux-arm-server-release/support/link_opt/classlist.jsa \ -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -Duser.language=en -Duser.country=US \ --module-path /home/pi/boris/jdk/build/linux-arm-server-release/support/classlist.jar \ -cp /home/pi/boris/jdk/build/linux-arm-server-release/support/classlist.jar build.tools.classlist.HelloClasslist 3. > const Register Rresult = R0; // <---- > assert_different_registers(Robj, Rmark, Rlock, R0, Rtemp); // <--- R0 sho2uld actually be Rresult? Yes, this is a suspicious place. But note that Rresult=R0 is not actually used in the code. 4. > This is the error message I see on every build: > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/workspace/src/hotspot/share/asm/register.hpp:160), pid=14718, tid=14723 > # assert(a != b && a != c && a != d && a != e && b != c && b != d Yes, this assert fires on fastdebug build. My bad, I have not checked fastdebug build. 5. The original issue was that call_VM_leaf parameter is moved from R1 to R0 with call_VM->call_VM_leaf change. My first idea was to fix the issue in place: > https://github.com/bulasevich/jdk/commit/92e51c20fff08714ccc07a5c8b568686853787f2 but later I decided to change unlock_object to use right register from the very beginning. I am going to check if my original idea works better on RPI. (I am kind of limited with experiments because on my RPi jdk build takes 5 hours).
15-10-2020
I can reproduce it reliably on RPi 4 build. I think it it is the clash with Rresult: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/interp_masm_arm.cpp#L999-L1000 const Register Rresult = R0; // <---- assert_different_registers(Robj, Rmark, Rlock, R0, Rtemp); // <--- R0 should actually be Rresult?
13-10-2020
This is the error message I see on every build: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/src/hotspot/share/asm/register.hpp:160), pid=14718, tid=14723 # assert(a != b && a != c && a != d && a != e && b != c && b != d && b != e && c != d && c != e && d != e) failed: registers must be different: a=0x00000002, b=0x00000003, c=0x00000000, d=0x00000000, e=0x0000000c # # JRE version: (16.0) (fastdebug build ) # Java VM: OpenJDK Server VM (fastdebug 16-internal+0-adhoc..workspace, mixed mode, g1 gc, linux-arm) # Problematic frame: # V [libjvm.so+0x757214] InterpreterMacroAssembler::unlock_object(RegisterImpl*) [clone .part.34]+0x63 # # Core dump will be written. Default location: /workspace/make/core # # An error report file with more information is saved as: # /workspace/make/hs_err_pid14718.log # # /bin/bash: line 1: 14718 Aborted (core dumped) /workspace/build/linux-arm-server-fastdebug/jdk/bin/java -Xms64M -Xmx768M -cp /workspace/build/linux-arm-server-fastdebug/buildtools/tools_jigsaw_classes --add-exports java.base/jdk.internal.module=ALL-UNNAMED build.tools.jigsaw.AddPackagesAttribute /workspace/build/linux-arm-server-fastdebug/jdk > >(/usr/bin/tee -a /workspace/build/linux-arm-server-fastdebug/jdk/_optimize_image_exec.log) 2> >(/usr/bin/tee -a /workspace/build/linux-arm-server-fastdebug/jdk/_optimize_image_exec.log >&2)
13-10-2020