adoptium / adoptium/adoptium-support

Temurin 17.0.7 crashes occasionally on MacOS machine with M1 chip

Open
#810 17 comments 0 reactions 0 assignees View on GitHub
bug jbs:reported keep
Dominant language
No language data
Stars
59
Forks
13
PR merge metrics
No merged PRs in 30d

Description

### Please provide a brief summary of the bug

In certain cases - when starting an application from IntelliJ Idea it crashes with a bug that looks very similar to something that appears to have been fixed in one of the previous releases, i.e.:
Internal Error (assembler_aarch64.hpp:267), pid=2929, tid=25347

### Please provide steps to reproduce where possible

Hard to reproduce exactly when it happens - sometime during the application startup.

### Expected Results

JDK not to crash.

### Actual Results

JDK crashes

### What Java Version are you using?

openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment Temurin-17.0.7+7 (build 17.0.7+7) OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode)

### What is your operating system and platform?

MacOS Ventura 13.4, ARM64 / M1

### How did you install Java?

Through homebrew.

### Did it work before?

```Shell
Hard to say as this is a new application - never had the same conditions before.
```

### Did you test with the latest update version?

```Shell
Yes.
```

### Did you test with other Java versions?

```Shell
Yes, with Zulu 17 as well as Oracle, both crash.
```

### Relevant log output

```Shell
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (assembler_aarch64.hpp:267), pid=2929, tid=25347
# guarantee(chk == -1 || chk == 0) failed: Field too big for insn
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.7+7 (17.0.7+7) (build 17.0.7+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (17.0.7+7, mixed mode, emulated-client, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# https://github.com/adoptium/adoptium-support/issues
#

--------------- S U M M A R Y ------------

Command Line: -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:64579,suspend=y,server=n -XX:TieredStopAtLevel=1 -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote -Dspring.jmx.enabled=true -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -Dmanagement.endpoints.jmx.exposure.include=* -javaagent:/Users/bos/Library/Caches/JetBrains/IntelliJIdea2023.1/captureAgent/debugger-agent.jar -Dfile.encoding=UTF-8 care.better.demographics.DemographicsApplicationKt --spring.config.additional-location=./conf/

Host: "MacBookPro18,3" arm64, 10 cores, 16G, Darwin 22.5.0, macOS 13.4 (22F66)
Time: Fri Jun 2 13:59:01 2023 CEST elapsed time: 21.592415 seconds (0d 0h 0m 21s)

--------------- T H R E A D ---------------

Current thread (0x000000011e018200): JavaThread "C1 CompilerThread1" daemon [_thread_in_native, id=25347, stack(0x000000016ef30000,0x000000016f133000)]

Current CompileTask:
C1: 21592 18532 %s 1 care.better.demographics.index.indexing.param.DatabaseAwareSearchParameterRetriever::syncSearchParametersIfNecessary @ 89 (1754 bytes)

Stack: [0x000000016ef30000,0x000000016f133000], sp=0x000000016f1319a0, free space=2054k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0xa1a1d8] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x490
V [libjvm.dylib+0xa1a95c] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40
V [libjvm.dylib+0x2c5188] report_vm_error(char const*, int, char const*, char const*, ...)+0x78
V [libjvm.dylib+0x872478] Address::encode_pair(Instruction_aarch64*) const+0x128
V [libjvm.dylib+0x8722fc] Assembler::ld_st1(int, int, int, int, RegisterImpl*, RegisterImpl*, Address, bool)+0x20c
V [libjvm.dylib+0x1a320c] LIR_Assembler::osr_entry()+0x1e8
V [libjvm.dylib+0x1a10d0] LIR_Assembler::emit_lir_list(LIR_List*)+0x9c
V [libjvm.dylib+0x1a1178] LIR_Assembler::emit_code(BlockList*)+0x74
V [libjvm.dylib+0x17333c] Compilation::emit_code_body()+0xe0
V [libjvm.dylib+0x1739e4] Compilation::compile_java_method()+0x354
V [libjvm.dylib+0x173c1c] Compilation::compile_method()+0x124
V [libjvm.dylib+0x173fb0] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x19c
V [libjvm.dylib+0x1751cc] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x5c
V [libjvm.dylib+0x2a0c7c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x528
V [libjvm.dylib+0x2a06bc] CompileBroker::compiler_thread_loop()+0x440
V [libjvm.dylib+0x9ac384] JavaThread::thread_main_inner()+0x150
V [libjvm.dylib+0x9aaa0c] Thread::call_run()+0xe0
V [libjvm.dylib+0x7ca4c8] thread_native_entry(Thread*)+0x158
C [libsystem_pthread.dylib+0x6fa8] _pthread_start+0x94

(truncated to get under 64k limit)
```

Contributor guide

Open the contributing guide

Research direction

Start with the fatal-error log at assembler_aarch64.hpp:267 and the C1 CompilerThread1 stack, especially the AArch64 assembler and LIR_Assembler frames. The report names no source file or test; done would require reproducing or isolating the crash on macOS ARM64 and verifying that the JVM no longer fails during the reported compilation path.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, macos
Domain
operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.