JDK-8287129 : TestStressCodeBuffers.java crashes on macosx_aarch64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.16-oracle
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2022-05-23
  • Updated: 2022-12-14
  • Resolved: 2022-09-05
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 11
11-poolResolved
Related Reports
Duplicate :  
JDK-8272094 - compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline"
Relates :  
JDK-8270947 - AArch64: C1: use zero_words to initialize all objects
Description
Test: TestStressCodeBuffers.java
OS: macosx-aarch64-debug
Where: 11.0.16-oracle
Is it a regression: No (failing after adding macosx_aarch64 build support)
vm options: "-XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation"
Frequency of failure: Intermittent 
Log:
----------System.out:(27/1668)----------
StressCodeBuffers: have expanded 128 times
StressCodeBuffers: have expanded 256 times
StressCodeBuffers: have expanded 512 times
StressCodeBuffers: have expanded 1024 times
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000106676914, pid=37862, tid=43267
#
# JRE version: Java(TM) SE Runtime Environment 18.9 (11.0.17+1) (fastdebug build 11.0.17-ea+1-LTS-67)
# Java VM: Java HotSpot(TM) 64-Bit Server VM 18.9 (fastdebug 11.0.17-ea+1-LTS-67, compiled mode, compressed oops, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x66914]  Assembler::emit_long(int)+0x34
#
# Core dump will be written. Default location: /cores/core.37862
#
# An error report file with more information is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S53076/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d6b09c36-2be7-4e68-9cba-012b1a796104/runs/4eef8282-0cae-4a73-9f02-2c4f4871c817/testoutput/test-support/jtreg_open_test_hotspot_jtreg_compiler_codecache_TestStressCodeBuffers_java/scratch/0/hs_err_pid37862.log
#
# Compiler replay data is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S53076/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d6b09c36-2be7-4e68-9cba-012b1a796104/runs/4eef8282-0cae-4a73-9f02-2c4f4871c817/testoutput/test-support/jtreg_open_test_hotspot_jtreg_compiler_codecache_TestStressCodeBuffers_java/scratch/0/replay_pid37862.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 43267
Dumping core ...
Comments
This issue was observed only twice in the same mach5 run. I couldn't reproduce either from local run. After running 100 times on mach5 there is no issue observed https://mach5.us.oracle.com/mdash/jobs/fmatte-jdk11u-cpu-20220530-1323-32900798 Looking into how the crash happened, thanks [~burban] for quickly looking into it. The failure happened in emit_int32(0x14000000) in the assembler, because it tries to emit that value into 0xfffffffffffffffe which I don’t get how this is possible, especially in the middle of a macro For now, I am closing this as cannot reproduce, will reopen this once the issue reappears again.
30-05-2022
Possibly related to JDK-8270947 and JDK-8272094.
23-05-2022