RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2]

[Johan Sjölen]

On Thu, 4 Sep 2025 08:47:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> David Holmes 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8364735-xtty
>>  - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown
>
> Okay. I would like it more if these objects were immortal. 
> 
> Side note, I would love some concept of immortal objects at some point; a way to clearly indicate (and assert) that we intend to keep an object around forever.

@tstuefe 

> Side note, I would love some concept of immortal objects at some point; a way to clearly indicate (and assert) that we intend to keep an object around forever.


// The purpose of this class is to provide control over the initialization
// time for an object of type T with static storage duration. An instance of
// this class provides storage for an object, sized and aligned for T. The
// object must be explicitly initialized before use. This avoids problems
// resulting from the unspecified initialization time and ordering between
// different objects that comes from using undeferred objects (the so-called
// "Static Initialization Order Fiasco).
//
// Once initialized, the object is never destroyed. This avoids similar issues
// with the timing and ordering of destruction on normal program exit.
//
// T must not be a reference type. T may be cv-qualified; accessors will
// return a correspondingly cv-qualified reference to the object.
template<typename T>
class DeferredStatic {


> // Once initialized, the object is never destroyed. This avoids similar issues
> // with the timing and ordering of destruction on normal program exit.

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

PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3252913500