RFR: JDK-8292351: tty should always live [v4]

Thomas Stuefe stuefe at openjdk.org
Wed Aug 17 18:33:17 UTC 2022


On Wed, 17 Aug 2022 09:30:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The default stream object tty is used in many places but its lifetime is limited. It gets born not-quite at the beginning of VM initialization and dies in DestroyVM. This leaves time windows before VM initialization and after VM cleanup where logging to tty crashes.
>> 
>> This has been bugging me in the past, especially when wanting to use tty in code that runs very early (NMT preinit system, for example), and also causes problems for code that runs post-cleanup. Mostly this affects logging and error logging.
>> 
>> tty should always be safe to write to, and that is trivial to do.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment

(I'm spending way to much time on this)

Here is the compatibility situation wrt tty=NULL before and after my patch.

- Writing to tty before VM initialization:
  - Before patch: 
    - Standard java launcher: results in a core dump. More or less silent VM death. We *may* see "Segmentation Fault" if parent process is a shell, on the shell's stderr; text may work its way via the shell's stderr stream into log files.
    - If custom launcher, and custom launcher installed its own signal handlers, the SIGSEGV will be catched by that handler. All bets are open. But most handlers I have seen just abort the VM on SIGSEGV, finger-pointing to the "broken" Java VM.
  - After patch: We see the message the calling code intended to send on stderr.

- Writing to tty after VM cleanup
  -  Before the patch: Will result in an error report written to *stdout* (not tty), and a hs-err file. The hs-err file will be broken in many places by secondary crashes since error handling also uses tty and does not check if it is valid. Highly likely we will exceed the max. number of secondary crashes and just abort the error handling.
  - After the patch: We see the message the calling code intended to send on stderr.

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

PR: https://git.openjdk.org/jdk/pull/9874


More information about the hotspot-dev mailing list