-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P2
-
Affects Version/s: 25.0.1
-
Component/s: hotspot
-
x86_64
-
linux
ADDITIONAL SYSTEM INFORMATION :
Reproduced on different systems
- MacOS w/latest Docker Desktop
uname -a => Linux 9b6b4ecf0e6a 6.10.14-linuxkit #1 SMP Wed Sep 10 06:47:45 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
- AWS EC2 Graviton running Amazon Linux 2
uname -a => Linux 75bf5fc946 5.10.244-240.965.amzn2.aarch64 #1 SMP Sat Sep 20 21:53:18 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
Exclusively observed on aarch64
Reproduced with base container `azul/zulu-openjdk:25`:
openjdk version "25.0.1" 2025-10-21 LTS
OpenJDK Runtime Environment Zulu25.30+17-CA (build 25.0.1+8-LTS)
OpenJDK 64-Bit Server VM Zulu25.30+17-CA (build 25.0.1+8-LTS, mixed mode, sharing)
Also reproduced with base container `eclipse-temurin:25-jdk`
openjdk version "25" 2025-09-16 LTS
OpenJDK Runtime Environment Temurin-25+36 (build 25+36-LTS)
OpenJDK 64-Bit Server VM Temurin-25+36 (build 25+36-LTS, mixed mode, sharing)
NOT reproducible on `eclipse-temurin:24-jdk`:
openjdk version "24.0.2" 2025-07-15
OpenJDK Runtime Environment Temurin-24.0.2+12 (build 24.0.2+12)
OpenJDK 64-Bit Server VM Temurin-24.0.2+12 (build 24.0.2+12, mixed mode, sharing)
A DESCRIPTION OF THE PROBLEM :
We have a few HTTP server applications we're trying to update to run on java 25, from java 21. We make regular use of JFR recording in our CI/CD pipeline, and in production. With java 25, we've observed this SIGSEGV on each application when a JFR recording is started, exclusively on arm64, with the problematic frame contained by the same method (next_vframe) every time.
Both applications where this has been observed are Eclipse Vert.x (v5.0.5) HTTP server applications with Kafka producers.
The issue reliably occurs on java 25.0.1 (using containers azul/zulu-openjdk:25 and eclipse-temurin:25-jdk), but does not occur on java 24.0.2 (using container eclipse-temurin:24-jdk)
REGRESSION : Last worked in version 24
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Start the application
2. Start a JFR recording
3. Submit any HTTP requests to the application
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application handles the requests normally, JFR recording can be stopped and saved successfully
ACTUAL -
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000ffff8154a4b4, pid=1, tid=112
#
# JRE version: OpenJDK Runtime Environment Temurin-25+36 (25.0+36) (build 25+36-LTS)
# Java VM: OpenJDK 64-Bit Server VM Temurin-25+36 (25+36-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x94a4b4] JfrVframeStream::next_vframe()+0x234
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# JFR recording file will be written. Location: /app/hs_err_pid1.jfr
#
# An error report file with more information is saved as:
# /app/hs_err_pid1.log
[69.390s][warning][os] Loading hsdis library failed
[thread 42 also had an error]
[thread 203 also had an error]
[thread 34 also had an error]
[thread 115 also had an error]
------ Timeout during error reporting after 120 s. ------
# [ timer expired, abort... ]
[thread 19 also had an error]
[thread 43 also had an error]
Reproduced on different systems
- MacOS w/latest Docker Desktop
uname -a => Linux 9b6b4ecf0e6a 6.10.14-linuxkit #1 SMP Wed Sep 10 06:47:45 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
- AWS EC2 Graviton running Amazon Linux 2
uname -a => Linux 75bf5fc946 5.10.244-240.965.amzn2.aarch64 #1 SMP Sat Sep 20 21:53:18 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
Exclusively observed on aarch64
Reproduced with base container `azul/zulu-openjdk:25`:
openjdk version "25.0.1" 2025-10-21 LTS
OpenJDK Runtime Environment Zulu25.30+17-CA (build 25.0.1+8-LTS)
OpenJDK 64-Bit Server VM Zulu25.30+17-CA (build 25.0.1+8-LTS, mixed mode, sharing)
Also reproduced with base container `eclipse-temurin:25-jdk`
openjdk version "25" 2025-09-16 LTS
OpenJDK Runtime Environment Temurin-25+36 (build 25+36-LTS)
OpenJDK 64-Bit Server VM Temurin-25+36 (build 25+36-LTS, mixed mode, sharing)
NOT reproducible on `eclipse-temurin:24-jdk`:
openjdk version "24.0.2" 2025-07-15
OpenJDK Runtime Environment Temurin-24.0.2+12 (build 24.0.2+12)
OpenJDK 64-Bit Server VM Temurin-24.0.2+12 (build 24.0.2+12, mixed mode, sharing)
A DESCRIPTION OF THE PROBLEM :
We have a few HTTP server applications we're trying to update to run on java 25, from java 21. We make regular use of JFR recording in our CI/CD pipeline, and in production. With java 25, we've observed this SIGSEGV on each application when a JFR recording is started, exclusively on arm64, with the problematic frame contained by the same method (next_vframe) every time.
Both applications where this has been observed are Eclipse Vert.x (v5.0.5) HTTP server applications with Kafka producers.
The issue reliably occurs on java 25.0.1 (using containers azul/zulu-openjdk:25 and eclipse-temurin:25-jdk), but does not occur on java 24.0.2 (using container eclipse-temurin:24-jdk)
REGRESSION : Last worked in version 24
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Start the application
2. Start a JFR recording
3. Submit any HTTP requests to the application
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application handles the requests normally, JFR recording can be stopped and saved successfully
ACTUAL -
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000ffff8154a4b4, pid=1, tid=112
#
# JRE version: OpenJDK Runtime Environment Temurin-25+36 (25.0+36) (build 25+36-LTS)
# Java VM: OpenJDK 64-Bit Server VM Temurin-25+36 (25+36-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x94a4b4] JfrVframeStream::next_vframe()+0x234
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# JFR recording file will be written. Location: /app/hs_err_pid1.jfr
#
# An error report file with more information is saved as:
# /app/hs_err_pid1.log
[69.390s][warning][os] Loading hsdis library failed
[thread 42 also had an error]
[thread 203 also had an error]
[thread 34 also had an error]
[thread 115 also had an error]
------ Timeout during error reporting after 120 s. ------
# [ timer expired, abort... ]
[thread 19 also had an error]
[thread 43 also had an error]