JVM crash with SIGSEGV when running spark executor process - Corretto-17.0.16.8.1

[guanlin84]

Describe the bug

When we submit a job on spark 3.5.5 in standalone mode, the JVM running the spark executor process crashes, leading to job failures. Spark retries the job 4 times, each time a new executor is created and then crashing again.

JVM crashed with SIGSEGV when running spark executor process, see hs_err_pid5644.log and replay_pid5644.log

Also tried with options -XX:-UseTieredCompilation -XX:+UseG1GC which didn't help, see hs_err_pid7051.log and replay_pid7051.log

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007ff1bd689fa9, pid=5644, tid=5661
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.16.8.1 (17.0.16+8) (build 17.0.16+8-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.16.8.1 (17.0.16+8-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x689fa9]  Dictionary::find(unsigned int, Symbol*, Handle)+0x39

To Reproduce

N/A

Expected behavior

JVM should not crash.

Screenshots

N/A

Platform information

OS: Amazon Linux release 2023.8.20250818 (Amazon Linux)
Version: OpenJDK Runtime Environment Corretto-17.0.16.8.1 (17.0.16+8) (build 17.0.16+8-LTS)

Additional context

[synecdoche]

I'm sorry you're experiencing this, and thank you for taking the time to open a GitHub issue, along with sending the hs_dist file.

This looks like it's crashing 9 seconds into the process in the C1 JIT compiler.

While we investigate further, I have a few questions:

• I am unfamiliar with Spark. Is it possible to provide simple reproduction steps to help us debug this further?

• Is this a new crash? That is, did you experience this crash with a different version of the JDK?

• Would you be willing to try it with Corretto 21 and let us know if you experience the crash with that version?

[synecdoche]

@guanlin84 Could you try with each of the following options (one at a time) and see if either of them gets around the crash?

• -XX:-ClassUnloadingWithConcurrentMark
• -XX:-ClassUnloading