JDK-8243196 : Take system native crash reporter into account when reporting any crash log info
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Withdrawn
  • OS: linux
  • Submitted: 2020-04-20
  • Updated: 2020-07-10
  • Resolved: 2020-07-10
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.
Other
tbdResolved
Related Reports
Relates :  
JDK-8059586 - hs_err report should treat redirected core pattern.
Relates :  
JDK-8244617 - If "CreateCoredumpOnCrash" is set, then we should call setrlimit(RLIMIT_CORE)
Relates :  
JDK-8237775 - Core file generation will silently fail if /cores directory has wrong permissions set
Relates :  
JDK-8237777 - "Dumping core ..." is shown despite claiming that "# No core dump will be written."
Description
When we crash, we display info such as:

"Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E", or dumping to /home/gerard/Desktop/core.13857

According to https://wiki.ubuntu.com/Apport the "apport" program is disabled by default. There is a way to check if it's enabled/disabled, that we could use to know exactly if apport is used and therefore the format of the "core" file name.

http://man7.org/linux/man-pages/man5/core.5.html explains the mechanism that is used to determine the exact pattern used for the core file name.

Not sure yet if apport applies to other distributions, such as Oracle Linux, or just Ubuntu.
Comments
#1 Should be addressed at the minimum. The rest have higher cost to benefit ratio, and we can discuss/address them separately. My counter argument to "power user" comments are that: a) power users are not born as power users, everyone start as a normal users and they have to learn it first somehow, so we should be helpful to them, not vague if we can b) power users often get core files from normal users, it would be helpful for those normal users to know where to look for them, without the power users having to engage
30-04-2020
There is not, AFAIK, any standard way to determine exactly how a given system will process core files. We make a best effort given what information we do have. #1 - we should be able to easily address this with a message #2 - s/will/may/ #3 - see first statement above #4 - again see first statement above With regard to #5 it is hardly "programmatic" as we simply read the core_pattern from the file system. As I wrote in a previous comment trying to parse that to determine if the listed "program" is available and enabled is something that may not even be possible as we don't know the set of potential programs or anything about them. While we can make some improvements I'm not seeing a winning cost:benefit ratio here. We're talking about a lot of effort for little benefit. And testing requires a wide range of distributions with different configurations - which we don't have ready access to. In addition, developers are power users and they will know how core files are handled on their systems. End users may not but they will just file a bug and then potentially engage with support engineers who will also know how to locate core files.
29-04-2020
Results of running "jdk/bin/java -XX:ErrorHandlerTest=12", showing relevant info only (all OS use default settings wrt core files): Ubuntu (v.18 & v.20) NO "ulimit -c unlimited": # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/gerard/Desktop/Work/bugs/8237777/jdk15/build/linux-x64/images/core.2735) Current thread is 2736 Dumping core ... Aborted (core dumped) Core file note: no core file Ubuntu (v.18 & v.20) WITH "ulimit -c unlimited": # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /home/gerard/Desktop/Work/bugs/8237777/jdk15/build/linux-x64/images/core.2774) Current thread is 2775 Dumping core ... Aborted (core dumped) Core file note: /home/gerard/Desktop/Work/bugs/8237777/jdk15/build/linux-x64/images/core SolarisLinux (v.7) NO "ulimit -c unlimited": # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/gerard/Downloads/core.5827) Current thread is 5828 Dumping core ... Aborted (core dumped) Core file note: /var/lib/systemd/coredump/core.java.1000.9b8dcb5722ba45efa9ca68e19206fced.5827.1588103385000000.lz4 SolarisLinux (v.7) WITH "ulimit -c unlimited": # Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/gerard/Downloads/core.5968) Current thread is 5969 Dumping core ... Aborted (core dumped) Core file note: /var/lib/systemd/coredump/core.java.1000.9b8dcb5722ba45efa9ca68e19206fced.5968.1588103441000000.lz4 Mac OS X (v. 10.15) NO "ulimit -c unlimited": # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again Current thread is 6659 Dumping core ... [1] 58299 abort ./jdk/bin/java -XX:ErrorHandlerTest=12 Core file note: no core file Mac OS X (v. 10.15) WITH "ulimit -c unlimited": # Core dump will be written. Default location: /cores/core.58392 Current thread is 7171 Dumping core ... [1] 58392 abort (core dumped) ./jdk/bin/java -XX:ErrorHandlerTest=12 Core file note: /cores/core.58392
29-04-2020
Summary of the above, even after the upcoming fix for JDK-8237777, we will still be left with the following issues: #1 No helpful message about missing "ulimit -c unlimited" on all Linux distros #2 We claim that "# Core dump will be written.", yet no core files on Ubuntu (and other Linux distributions) without "ulimit -c unlimited" #3 The actual core file does not match the one we claim will be written on Ubuntu (and other Linux distributions), i.e. we claim "(or dumping to .../core.2774) ", but only "core" name is used (i.e. no PID) #4 The actual location of the core file does not match the one we claim on Linux Solaris (and Redhat, ? etc..), i.e. we claim "(or dumping to /home/gerard/Downloads/core.5968)" but it ends up in "/var/lib/systemd/coredump/". Also the file name uses a different pattern from the one we claim. #5 We sidestep the issue of whether the core will be processed by saying "Core dumps may be processed with", yet we can actually determine that programmatically. The state of core file info we currently present to our developers is, IMHO, subpar and we can and should do better.
29-04-2020
In ABRT (which is provided in RHEL / CentOS 6 AFAIK), its executable would be set to /proc/sys/kernel/core_pattern with '|'. If ABRT daemon (abrt-ccpp) is not run, the core is dumped to default location (<cwd>/core.<PID>) in spite of setting core_pattern. I guess is is similar to Apport. In Fedora and RHEL 8, systemd-coredump is enabled by default. It would store cores to own area, thus we need to access them with `coredumpctl`. Thus I think we should report the core is handled in other executable when /proc/sys/kernel/core_pattern starts with '|'.
23-04-2020
Some Linux distributions are "broken" in this regard as they define a core pattern involving a program that may not even be installed, let alone enabled. But that is a bug in those distributions IMO. I don't see any issue for us to fix here. We report what the core pattern states. We do not want to be parsing the core pattern to go and determine what program is going to be used to process core files and then whether that program is installed or not, or then enabled or not.
22-04-2020
Previous code change in this area: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/30ed7423ae23
22-04-2020