RFR: 8368551: Core dump warning may be confusing

Thomas Stuefe stuefe at openjdk.org
Tue Nov 18 13:19:10 UTC 2025


On Tue, 18 Nov 2025 07:03:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/posix/os_posix.cpp line 132:
>> 
>>> 130:         buf.print("core dumps may be processed with ");
>>> 131:       }
>>> 132:       buf.print("%s", core_path);
>> 
>> The only thing I don't like here is this part. I know it looks weird to have "Default location:  Core dumps may be processed with ..." but I think it is less informative to skip pointing out that this case is not actually a location at all.
>
> Or getting rid of the double negative, I think it is beneficial to always point out that this is not actually a location.

Yes, I agree.

The underlying problem is that `get_core_path()` needs to be redesigned for modern times (since Linux 2.4 that is :-) ) and that what the OS does with a core may not be "write it to the filesystem at this path" but "send it to someone".

A better approach would be just to implement all the "where is the core file?" printout functionality in an OS-dependent function and give up on the idea of POSIX-generic printing. Something like `os::Posix::print_core_file_setup()`, but implemented separately for AIX, BSD, and Linux.

- AIX can suggest a name depending on the AIX-specific `CORE_NAMING` env var. 
- BSD could write a name depending on `sysctl kern.core`. 
- Linux could do some basic parsing of `core_pattern` and either write "is processed with xxx" or "written to xxx" depending on the result. If `core_pattern` is really simple (e.g. no leading pipe symbol and only contains `%P`), it could even guess the file name.

But this would increase the scope of this RFE, and open it to a lot of bikeshedding, and I don't know about backward compatibility (scripts parsing this output) either - so I am absolutely fine with the minor improvements this patch does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538152660


More information about the hotspot-runtime-dev mailing list