RFR: 8374341: Use of "\s" instead of "\\s" in CoreUtils.java results in splitting on backspace instead of whitespace [v4]

[Kevin Walls]

On Wed, 7 Jan 2026 12:48:29 GMT, Eunbin Son <duke at openjdk.org> 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