RFR: 8368551: Core dump warning may be confusing [v3]

[Thomas Stuefe]

On Mon, 24 Nov 2025 09:22:46 GMT, Paul Hübner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>> 
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.2618391 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be further processed by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> # [...]
>>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> #
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateC...
>
> Paul Hübner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8368551
>  - Reviewer suggestions.
>  - Merge branch 'master' into JDK-8368551
>  - Update doc.
>  - Overhaul some core messages again.
>  - Better posix coredump messages.

I am fine with this version, if @dholmes-ora requests are addressed. LGTM.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28174#pullrequestreview-3508978936