RFR: 8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped [v2]

[David Holmes]

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

test/lib/jdk/test/lib/util/CoreUtils.java line 224:

> 222:         // Find the core file name in the output.
> 223:         String coreWithPid;
> 224:         if (Platform.isLinux() && stringWithLocation.contains(ALT_LOCATION_STRING)) {

Why is this only done for Linux when previously it was done for "not Windows"? What is the core message on macOS?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29284#discussion_r2729688156