JDK-8237777 : "Dumping core ..." is shown despite claiming that "# No core dump will be written."
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-23
  • Updated: 2023-12-07
  • Resolved: 2020-05-06
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 11 JDK 15 JDK 8
11.0.23-oracleFixed 15 b22Fixed 8u411Fixed
Related Reports
Relates :  
Relates :  
Description
# ./build/macosx-x86_64-server-fastdebug/images/jdk/bin/java -XX:ErrorHandlerTest=12 --version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x0000000107e39dc1, pid=65201, tid=7171
#
# JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-adhoc.gerard.open)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-adhoc.gerard.open, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0xc39dc1]  VMError::controlled_crash(int)+0x3cf
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Volumes/Work/bugs/0000000/jdk15/hs_err_pid65201.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 7171
Dumping core ...

No core file was generated in the above case.
Comments
Fix request [11u] I backport this for parity with 11.0.23-oracle. Remove print info. Clean backport. SAP nightly testing passed.
06-12-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2339 Date: 2023-12-05 06:22:27 +0000
05-12-2023

URL: https://hg.openjdk.java.net/jdk/jdk/rev/e4f974647009 User: gziemski Date: 2020-05-06 17:41:27 +0000
06-05-2020

Attached a diff for test/hotspot/jtreg/runtime/ErrorHandling/CreateCoredumpOnCrash.java which O originally intended to go with JDK-8237727, but is better suited here (even though it does the actual opposite to what this issue covers - might need to file a separate issue)
07-02-2020

ILW: MLM = P4
28-01-2020

Yes and that is exactly the point I was making.
24-01-2020

Since the VM is intelligent enough to say "# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again", it should avoid printing the "Dumping core ..." message: ./os/linux/os_linux.cpp: out.print_raw_cr("Dumping core ..."); ./os/solaris/os_solaris.cpp: out.print_raw_cr("Dumping core ..."); ./os/bsd/os_bsd.cpp: out.print_raw_cr("Dumping core ..."); ./os/aix/os_aix.cpp: out.print_raw_cr("Dumping core ...");
24-01-2020

I think this is the case on all platforms. The message is printed based on the dumpCore parameter passed to os::abort. That parameter has no connection to what we do in os::check_dump_limit which may have determined that core dumping is disabled.
23-01-2020