RFR: 8368551: Core dump warning may be confusing
Paul Hübner
phubner at openjdk.org
Tue Nov 18 13:34:03 UTC 2025
On Tue, 18 Nov 2025 12:59:47 GMT, Thomas Stuefe <stuefe 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 core path is unknown, trying core.1552174 (may not exist)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.1552174 (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 processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)
>>
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>>
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c u...
>
> src/hotspot/os/posix/os_posix.cpp line 128:
>
>> 126: buf.print("core.%d (may not exist)", current_process_id());
>> 127: #ifdef LINUX
>> 128: } else if (core_path[0] == '"') { // redirect to user process
>
> Pre-existing, but the double quote is odd? Should this not be a pipe symbol? See `man core(5)`.
Strange, right? It's the result of preprocessing done in `os_linux.cpp`'s `os::get_core_path` that checks if `core_pattern[0] == '|'`:
written = jio_snprintf(buffer, bufferSize,
""%s" (or dumping to %s/core.%d)",
&core_pattern[1], p, current_process_id());
You can see these quotes in the output:
> "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538245509
More information about the hotspot-runtime-dev
mailing list