RFR: 8338883: Add core dump info to -Xlog:os=info [v5]

[Thomas Stuefe]

On Tue, 10 Sep 2024 15:03:23 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We add a small feature, which adds core dump info, which till now was only printed as part of hs_err log file, directly to stdout, when desired using log mechanism, i.e. `-Xlog:os=info`
>> 
>> For example, if we see:
>> 
>> `core dump info: core.28283`
>> 
>> we know all is set up correctly and we can expect a core file if java process crashes. If we see:
>> 
>> `core dump info: Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again`
>> 
>> instead, however, we know that "ulimit -c unlimited" needs to be set.
>> 
>> Testing: 
>> - passes `"MACH5 runtime/ErrorHandling/CreateCoredumpOnCrash.java"`
>> - full MACH5 test in progress...
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix PATH_MAX on Windows, use check_only for record_coredump_status

The name of the core dump file is not that useful, and it is potentially confusing since it appears to the casual analyst as if there is a core file somewhere. Moreover, with Linux and core dump crash demons, the printed name is often wrong, at least in my experience.

It is useful to check, at VM start, whether cores would be prevented were they to happen, but only if the caller is interested in core files. But in that case, a timid info in some log is not useful. Nobody but you will probably remember this code exists, let alone activating the log and looking for the info.

If the user really wants core dumps, it would be better to check ulimit at startup and do a clear unconditional warning() or even an vm_exit_during_initialization(). But we should not do this if the limit is large enough, even if it is not unlimited. E.g. many customers set core file limits to something like 4g or somesuch. If the VM was started with 128MB, we will probably reach the 4G.

Proposal:
- if both `CreateCoredumpOnCrash`=1 *and* it had been explicitly enabled at the command line, write an unconditional warning using the warning() function if it looks like core files would be prevented
- Even if limit is not unlimited, don't warn for cases where limit is high enough for the current projected footprint. Can be a simple logic depending on max heap size, e.g. max heap size * 4.
- The future core file name is unimportant since we will print it out anyway when we crash. If you remove that part, the patch becomes a lot simpler, since it would be limited to an ulimit check at startup if `CreateCoredumpOnCrash=1`.


Just my 5 cents,

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/20734#issuecomment-2341263447