JDK-8332506 : SIGFPE In ObjectSynchronizer::is_async_deflation_needed() causing JVM Crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2024-05-15
  • Updated: 2024-11-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24Unresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
Host: Intel(R) Xeon(R) Silver 4215R CPU @ 3.20GHz, 4 cores, 15G, Red Hat Enterprise Linux release 8.8 (Ootpa)
JRE version: OpenJDK Runtime Environment (Red_Hat-21.0.1.0.12-2) (21.0.1+12) (build 21.0.1+12-LTS)
Java VM: OpenJDK 64-Bit Server VM (Red_Hat-21.0.1.0.12-2) (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)

Note this a VMWare VM

A DESCRIPTION OF THE PROBLEM :
The JVM seemingly randomly crashed with a SIGFPE Error

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007fd1ebb1f331, pid=802111, tid=802127
#
# JRE version: OpenJDK Runtime Environment (Red_Hat-21.0.1.0.12-2) (21.0.1+12) (build 21.0.1+12-LTS)
# Java VM: OpenJDK 64-Bit Server VM (Red_Hat-21.0.1.0.12-2) (21.0.1+12-LTS, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xf46331]  ObjectSynchronizer::is_async_deflation_needed()+0x1e1




Comments
Additional Information from submitter: ================================================= I've run my application with 21.0.4 for for over 72 hours under the same circumstances as before, except dumping threads every 30s instead of a minute to encourage a reoccurrence. I am happy to report that I haven't experienced a crash. I'm assuming some combination of the below issues fixed the root cause of the crash, but, nothing definitive. JDK-8318757 - VM_ThreadDump asserts in interleaved ObjectMonitor::deflate_monitor calls JDK-8273107 - RunThese24H times out with "java.lang.management.ThreadInfo.getLockName()" is null JDK-8320515 - assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object
29-07-2024

Additional Information from Submitter: ============================ When reviewing JDK-8290786 (previous bug of this incident), the crash report in that ticket also includes "ThreadDump" entries under 'VM Operations'.
03-06-2024

ILW = HLM = P3
28-05-2024

I still can't see anything that would lead to a SIGFPE. But interesting that the thread dump triggers it.
24-05-2024

Additional Information from submitter to original bug report (JDK-8332506) ===================================================== I reported this happens randomly. I have since discovered this crash always occurs with a thread dump. The application was periodically (once a minute) performing a thread dump. The application would crash after ~30-38 hours of run time. Looking around for bugs on the JDK, I'm assuming this happens due to JDK-8318757, but have no concrete proof. In the initial report this happened on 21.0.1, I have since had it on 21.0.3. In both reports the application is using ZGC (single-gen) REGRESSION : Last worked in version 17 STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : Run the supplied code for up to 48 hours, at once a minute. Potentially increasing your odds for reproduction if ran at a higher rate. EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - No JVM Crash ACTUAL - JVM Crashed with SIGFPE. ---------- BEGIN SOURCE ---------- import java.io.ByteArrayOutputStream; import java.io.FileInputStream; import java.io.PrintStream; import java.lang.management.LockInfo; import java.lang.management.ManagementFactory; import java.lang.management.MonitorInfo; import java.lang.management.ThreadInfo; import java.lang.management.ThreadMXBean; import java.util.Arrays; import java.util.HashMap; import java.util.List; import java.util.Map; import java.util.stream.Collectors; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import org.apache.logging.log4j.core.config.ConfigurationSource; import org.apache.logging.log4j.core.config.Configurator; import globalstar.logging.Log; public class ThreadChecker implements Runnable{ private final Logger logger; public ThreadChecker() { logger = LogManager.getLogger("thread-logger"); } private void dumpJVMThreads(PrintStream pw) { ThreadMXBean b = ManagementFactory.getThreadMXBean(); if (b != null) { ThreadInfo[] tis = b.dumpAllThreads(b.isObjectMonitorUsageSupported(), b.isSynchronizerUsageSupported()); if (tis != null && tis.length != 0) { pw.println("\nWaiting JVM threads:"); for (ThreadInfo ti : tis) { Thread.State state = ti.getThreadState(); if (state != Thread.State.RUNNABLE && state != Thread.State.TERMINATED) { printThreadInfo(pw, ti); } } }else { pw.println("\nNo Waiting JVM Threads"); } }else { pw.println("\nUnable to get ThreadMXBean"); } } private boolean findJVMDeadlocks(PrintStream pw) {; ThreadMXBean b = ManagementFactory.getThreadMXBean(); if (b != null) { long[] ids = b.findDeadlockedThreads(); if (ids != null && ids.length != 0) { ThreadInfo[] tis = b.getThreadInfo(ids, b.isObjectMonitorUsageSupported(), b.isSynchronizerUsageSupported()); pw.print("\nDeadlocked Java threads found:\n\t"); List<String> threadNames = Arrays.stream(tis).map(ThreadInfo::getThreadName).collect(Collectors.toList()); pw.println(String.join(", ", threadNames)); return true; }else { pw.println("\nNo Deadlocked JVM Threads"); } }else { pw.println("\nUnable to get ThreadMXBean"); } return false; } private void printThreadInfo(PrintStream pw, ThreadInfo ti) { pw.println("\tThread \"" + ti.getThreadName() + "\" (" + hex(ti.getThreadId()) + ") " + ti.getThreadState()); LockInfo l = ti.getLockInfo(); if (l != null) { pw.println("\t\twaiting for " + format(l) + (ti.getLockOwnerName() == null ? "" : " held by " + ti.getLockOwnerName() + " (" + hex(ti.getLockOwnerId()) + ")")); } Map<StackTraceElement, MonitorInfo> mlocs = new HashMap<StackTraceElement, MonitorInfo>(); MonitorInfo[] mis = ti.getLockedMonitors(); if (mis.length > 0) { pw.println("\tMonitors held:"); for (MonitorInfo mi : mis) { mlocs.put(mi.getLockedStackFrame(), mi); pw.println("\t\t" + format(mi)); } } LockInfo[] lis = ti.getLockedSynchronizers(); if (lis.length > 0) { pw.println("\tSynchronizers held:"); for (LockInfo li : lis) { pw.println("\t\t" + format(li)); } } pw.println("\tStack trace:"); StackTraceElement[] stes = ti.getStackTrace(); for (StackTraceElement ste : stes) { pw.print("\t\t" + ste.getClassName() + "." + ste.getMethodName() + formatLineNumber(":", ste.getLineNumber())); if (mlocs.containsKey(ste)) { pw.print(" -> locked " + format(mlocs.get(ste))); } pw.println(); } pw.println(); } private String formatLineNumber(String prefix, int n) { if (n < 0) { return ""; } else { return prefix + String.valueOf(n); } } private String format(LockInfo l) { if (l != null) { return l.getClassName() + " (" + hex(l.getIdentityHashCode()) + ")"; } else { return "<unknown>"; } } private String hex(long x) { return String.format("0x%08x", x); } @Override public void run() { try { try (ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); PrintStream printStream = new PrintStream(byteArrayOutputStream);) { findJVMDeadlocks(printStream); dumpJVMThreads(printStream); String threadReport = byteArrayOutputStream.toString(); logger.info("\n=====Thread Report=====\n" +threadReport+ "\n=======End Report======\n"); } catch (Exception e) { logger.error("Error producing thread report",e); } }catch(Exception ex) { Log.warning("Error in thread checker",ex); } } } ---------- END SOURCE ----------
24-05-2024

Additional Information from submitter: ============================== Since filing this report, I've noticed that this crash coincides with a thread dump. The application in question performs a thread dump once a minute, as we attempted to use it to uncover a deadlock, The crash would happen after ~30-36 hours after runtime. Since disabling these periodic thread dumps, no crash has occurred. I'm assuming it has to do with a combination of JDK-8318757 and JDK-8273107 since this issue did not occur on 17.0.8.
24-05-2024

The comments from JDK-8290786 remain the same - there is nowhere in our code that I can see that could introduce a floating-point division by zero, or an integer division by zero.
23-05-2024