JVM 21 crashes with SIGSEGV caused by virtual threads

[stepan-hrbacek-n-able]

Please provide a brief summary of the bug

JVM crashes on SEGSEGV error (segmentation fault) with following error indicating that this is caused by java virtual threads:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f9dab612127, pid=15662, tid=33827
#
# JRE version: OpenJDK Runtime Environment Temurin-21.0.1+12 (21.0.1+12) (build 21.0.1+12-LTS)
# Java VM: OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x69b127]  ContinuationEntry::set_enter_code(CompiledMethod*, int)+0x7
#
# 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: -XX:+UseG1GC -XX:ParallelGCThreads=40 -XX:ConcGCThreads=40 -Xlog:gc*,safepoint:/var/log/n-central/jetty/gc.log:time,uptime,level,tags:filecount=5,filesize=100M -XX:+AlwaysPreTouch -XX:-ClassUnloading -XX:-OmitStackTraceInFastThrow --add-exports=java.base/jdk.internal.util.random=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.math=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED --add-opens=java.base/java.time.zone=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.regex=ALL-UNNAMED --add-opens=java.xml/jdk.xml.internal=ALL-UNNAMED --add-opens=java.base/sun.util.calendar=ALL-UNNAMED -XX:+UseNUMA -Xmx56054m -Xms16015m -XX:MetaspaceSize=1024m -Xss256K -Djava.awt.headless=true -Dlog4j2.configurationFile=file:////opt/nable/webapps/ROOT/WEB-INF/classes/log4j2.xml -Dlog4j2.formatMsgNoLookups=true -Dorg.apache.cxf.Logger=org.apache.cxf.common.logging.Slf4jLogger -Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl -Djava.security.egd=file:/dev/./urandom -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Daxis.ServerConfigFile=/com/nable/dmsapi/server-config.wsdd -Dnetworkaddress.cache.ttl=60 -Djdk.tls.ephemeralDHKeySize=2048 -Dognl.security.manager -Djetty.home=/opt/jetty -Djetty.base=/opt/nable -Djava.io.tmpdir=/opt/nable/tmp /opt/jetty/start.jar start-log-file=/var/log/n-central/jetty/jetty-start.log jetty.state=/opt/nable/jetty.state jetty-started.xml

Host: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz, 40 cores, 157G, CentOS Linux release 7.9.2009 (Core)
Time: Mon Jun 17 04:07:34 2024 CDT elapsed time: 73403.522546 seconds (0d 20h 23m 23s)

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

Current thread (0x00007f8ad4007980):  JavaThread "ForkJoinPool-1-worker-1" daemon [_thread_in_vm, id=33827, stack(0x00007f8a0cf9d000,0x00007f8a0cfdd000) (256K)]

Stack: [0x00007f8a0cf9d000,0x00007f8a0cfdd000],  sp=0x00007f8a0cfda7f8,  free space=245k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x69b127]  ContinuationEntry::set_enter_code(CompiledMethod*, int)+0x7
V  [libjvm.so+0xda4673]  AdapterHandlerLibrary::create_native_wrapper(methodHandle const&)+0x493
V  [libjvm.so+0xb75ec3]  LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*)+0x2a3
V  [libjvm.so+0xb7666b]  LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0x1fb
V  [libjvm.so+0x8f7ee7]  InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x177
V  [libjvm.so+0x8f85a5]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x105
j  jdk.internal.vm.Continuation.run()V+122 [email protected]
j  java.lang.VirtualThread.runContinuation()V+71 [email protected]
j  java.lang.VirtualThread$$Lambda+0x00007f8e9dee3dd8.run()V+4 [email protected]
j  java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec()Z+4 [email protected]
j  java.util.concurrent.ForkJoinTask.doExec()I+10 [email protected]
j  java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+19 [email protected]
j  java.util.concurrent.ForkJoinPool.scan(Ljava/util/concurrent/ForkJoinPool$WorkQueue;II)I+211 [email protected]
j  java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+35 [email protected]
j  java.util.concurrent.ForkJoinWorkerThread.run()V+31 [email protected]

The only usage of virtual threads in the crashing program is using an executor created by:

java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()

The issue goes away after replacing it with a normal thread pool:

java.util.concurrent.Executors.newSingleThreadExecutor()

hs_err_pid15662.log

Did you test with the latest update version?

• [ ] Yes

Please provide steps to reproduce where possible

No response

Expected Results

JVM does not crash when using virtual threads.

Actual Results

JVM crashes with SIGSEGV when using virtual threads.

What Java Version are you using?

OpenJDK Runtime Environment Temurin-21.0.1+12 (21.0.1+12) (build 21.0.1+12-LTS)

What is your operating system and platform?

Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz, 40 cores, 157G, CentOS x64 Linux release 7.9.2009 (Core)

How did you install Java?

RPM

Did it work before?

No response

Did you test with other Java versions?

No response

Relevant log output

No response

[stepan-hrbacek-n-able]

I was unfortunately not able to test this with the latest JVM 21 release because the issue only occurs in a customer production environment where changing JVM version is hard...

[jerboaa]

There have been several fixes in the loom area of latest JDK 21, so please be sure to update and see if it still reproduces with a later version (21.0.3 currently, or 21.0.4 in two weeks time). Unfortunately, we cannot fix 21.0.1 only. Fixes can only be delivered with latest update releases (if it still reproduces).

[stepan-hrbacek-n-able]

Thank you @jerboaa 👍

[github-actions[bot]]

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.