JDK-8202287 : hs_err reports that coredump is generated while it isn't
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2018-04-25
  • Updated: 2018-08-14
  • Resolved: 2018-08-14
Related Reports
Relates :  
JDK-8059586 - hs_err report should treat redirected core pattern.
Description
The hs_err contains says 
Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I" (or dumping to /scratch/lmesnik/ws/jdk/build/linux-x64/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_TestJmapCore_java/scratch/0/core.1305)

even if coredumps are disabled (ulimit -c 0)
Comments
Triage: This is not on our current list of priorities. We will considered this feature if we receive additional customer requirements.
14-08-2018
Thanks David, I agree with you.
26-04-2018
The problem is that systems by default seem to have an abort-hook listed in core-pattern even if not actually installed and enabled. So no core gets produced through the hook and no user corefile gets created if the ulimit is zero. So instead of saying Core dump will be written it should say Core dump may be written and instead of the "(or dumping to /<user-path-to-possible-core-file>)" it should check rlimit and report if user core files are disabled, else show the alternate path.
26-04-2018
I don't think JDK-8059586 breaks it. https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L573 abrt-hook-ccpp can store coredump(s) when "ulimit -c" is zero. So I changed to show current message in hs_err log.
26-04-2018
Added Yasumasa to the watch list.
26-04-2018
I agree it looks like JDK-8059586 caused this. It seems to print the information first and check the rlimit value last. That said, many systems have the core-pattern incorrectly set up, so that it claims core files will be procssed by tools like apport, even if the tool is not even installed.
26-04-2018
The workaround is to check limit info: rlimit: STACK 8192k, CORE 0k, NPROC 4096, NOFILE 8192, AS infinity, DATA infinity, FSIZE infinity
25-04-2018
I suspect that following change breaks it: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/30ed7423ae23
25-04-2018