adoptium-support
adoptium-support copied to clipboard
Temurin 17.0.7 crashes occasionally on MacOS machine with M1 chip
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?
Hard to say as this is a new application - never had the same conditions before.
Did you test with the latest update version?
Yes.
Did you test with other Java versions?
Yes, with Zulu 17 as well as Oracle, both crash.
Relevant log output
#
# 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)
You may have found a C1 bug - but can I ask why you're forcing C1 only with -XX:TieredStopAtLevel=1?
To be honest, it must be a setting by IntelliJ Idea - I myself have not added any custom parameters.
@bostjanl what does syncSearchParametersIfNecessary do? Does it call out to native code?
As far as I know - NO. We do not use any extra native libs, just pure java (via kotlin), This call runs SQL query via jdbc driver to postgresql.
@bostjanl OK, we may need the core dump or the more dertailed log file. Are you able to upload the full log file? Also do you know if it always crashes in that same method?
I am adding err and replay logs. It does not always crash, but when it does it was always at the same place. Let me know if this is enough. hs_err_pid2929.log replay_pid2929.log
@bostjanl if you're allowed to share, can you past the contents of the syncSearchParametersIfNecessary function?
I am sorry, but I can't paste that whole function, is there any other way I can help reproduce?
Does it lead to a call in a JDBC driver?
Yes, almost in every call to this function. We use postgresql driver 42.5.4 here.
Hmmmmm, OK do you run this app outside of IntelliJ? I'd like to see it run without -XX:TieredStopAtLevel=1
When you mentioned this could be an issue I removed parameter -XX:TieredStopAtLevel=1 when running or debugging from IntelliJ. So far I have not had a crash.
OK, that might be enough to go on, I'll go digging.
https://bugs.openjdk.org/browse/JDK-8310844
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
@bostjanl Have you tried 17.0.8?
Yes, but have not been able to crash it in the same place as before, but had a similar crash on a docker image built from 17.0.8 for arm64.