SIGSEGV in JfrVframeStream::next_vframe() on arm64

XMLWordPrintable

    • jfr
    • b26
    • x86_64
    • linux
    • Verified

        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]

              Assignee:
              Markus Grönlund
              Reporter:
              Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: