On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son <[email protected]> wrote:
>> ### Summary
>> Fix incorrect regex usage in CoreUtils.getCoreFileLocation.
>>
>> ### Description
>> CoreUtils.getCoreFileLocation uses String.split("\s", 2).
>> The string literal "\s" represents a backspace character, not a whitespace
>> regex.
>> As a result, the split operation does not separate fields on whitespace.
>> This change replaces the pattern with `"\\s+"` to correctly split on
>> whitespace.
>> No other logic is modified.
>>
>> ### Bug ID : JDK-8374341
>> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374341
>
> Eunbin Son has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views will show differences
> compared to the previous content of the PR. The pull request contains one new
> commit since the last revision:
>
> JDK-8374341: Remove unverified systemd-coredump handling code
Yes this has escalated a bit from the original typo submission.
AIUI, systemd-coredump is invoked at the time of the crash due to the |
coredump pattern, and will store the core in a directory that is not the pwd of
the process (so we might not find it), so this code tries to recognise that and
use coredumpctl to extract it.
Yes this code could have worked as intended if the core dump pattern with no
splitting ended in "systemd-coredump", but that does not look common (based on
a smal sample of systems I use...).
But coredumpctl also needs permission, which is not expected without being root
or some other config steps, so the extraction from the /var/... directory
generally fails. But that could have worked for some people when this was
originally added, just seems unlikely it works generally.
Internet searching summarises as: "coredumpctl needs root or privileged group
access (like systemd-journal) because it reads system journal/coredump files
usually owned by root in /var/lib/systemd/coredump, but you can grant specific
users access by adding them to the right group or using sudo to access their
own crashes..."
Yes, I think the sleep(5000) and loop we have currently are about waiting for
systemd-coredump to do its thing, and the core to be available in /var...
before running coredumpctl to try and extract it. This is probably useful, but
maybe it could have checked for more errors output from coredumptl and shown
them.
The current failure/fallback is fine for most users, it recognises that a core
dump pattern invokes a tool, and warns.
coredumpctl is currently invoked:
String core = "core";
ProcessTools.executeProcess("coredumpctl", "dump", "-1", "-o", core,
String.valueOf(pid));
dump
Extract the last core dump matching specified characteristics. The
core dump will be written on standard output, unless an output
file is specified with --output=.
-1
Show information of the most recent core dump only, instead of
listing all known core dumps. Equivalent to --reverse -n 1.
So it is also asking for the most recent coredump, which might be wrong if
there are multiple crashes around the same time.
MAYBE removing "-1" would be better, as this looks like it doesn't work if the
last core dump is not from PID.
But that's only worth looking at if there is a case that this coredumpctl code
can be made generally useful.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3749034948
