RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2]
Kevin Walls
kevinw at openjdk.org
Tue Jan 27 10:51:08 UTC 2026
On Mon, 26 Jan 2026 19:37:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> The support for locating zipped (and subsequently unzipped) core files broke when a message in the hs_err file changed, causing CoreUtils.java to not detect the alternate location of the core file. It became broken 2 months ago by the changes for [JDK-8368551](https://bugs.openjdk.org/browse/JDK-8368551). That changed the hotspot message related to the core file location that CoreUtils was searching for:
>>
>>
>> if (core_pattern[0] == '|') {
>> written = jio_snprintf(buffer, bufferSize,
>> - ""%s" (or dumping to %s/core.%d)",
>> + ""%s" (alternatively, falling back to %s/core.%d)",
>> &core_pattern[1], p, current_process_id());
>>
>>
>> CoreUtils was checking for "or ", but it needs to check for "alternatively...".
>>
>> Testing: I checked our CI runs, which used to skip all the SA core files tests on linux-x64 and linux-aarch64, and they are now running the tests and passing properly.
>
> Chris Plummer 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 four additional commits since the last revision:
>
> - Merge branch 'master' into 8375477_coreutils
> Merge
> - fix whitespace
> - get rid of unnecessary throws clause
> - fix zipped core file support
Looks good, added one question.
Also if the pattern is |/..../systemd-coredump then the core file ends up somewhere else entirely.
We give a useful message when skipping, so no need to describe that here as well.
There was an attempt to handle those cases but it's not realistic and should be removed in https://github.com/openjdk/jdk/pull/28984 - I pinged the submitter as that change was ready to go...
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29284#issuecomment-3804457396
More information about the serviceability-dev
mailing list