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
BTW, we currently have an issue with our own internal testing when dealing with
core files. Many hosts end up causing this "This system uses a crash report
tool.." message, so we end up skipping the core file tests. The cause is the
crash report tool being used to gzip the core file. I'm thinking of adding
support in CoreUtils to check for core.<pid>.gz, and unzip in that case. I
think the code to do this would go exactly where this PR is removing the
coredumpctl support.
And regarding the removal of the coredumpctl support, this is the review of the
change that introduced it:
https://mail.openjdk.org/pipermail/serviceability-dev/2021-January/035127.html
So this clearly worked at one point. However, in the original webrev (before
feedback and changes), the code was in CiReplayBase.java and did not do the
`endsWith("systemd-coredump")` check. So perhaps it worked then, but then when
it was moved to CoreUtils.java during the review process, it was broken and not
noticed.
I'm not so sure removing the coredumpctl support at this point is the right
thing to do. How was the \s error detected, and why do we think the right thing
to do at this point is to remove this support rather than fix it?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28984#issuecomment-3730330529
