-
Bug
-
Resolution: Fixed
-
P2
-
25
-
None
-
b03
There has been a latent problem in GDIHashtable since time immemorial, but due to sheer luck it has not caused any issues for us. However, I managed to provoke it when I was doing some build changes.
This is the problem:
In GDIHashtable, there is a static field GDIHashtable::BatchDestructionManager manager, which is initialized in GDIHashtable.cpp.
In AwtPen, there is a static field GDIHashtable cache, which is initialized in awt_Pen.cpp.
The GDIHashtable constructor calls manager.add(this).
For this to work, the manager must have been initialized prior to the AwtPen. However, the order of which static initializers are run between different compilation units are not well-defined, and we've just been lucky so far that it works.
This problem is known as the "Static Initialization Order Fiasco", see e.g. https://en.cppreference.com/w/cpp/language/siof
This is the problem:
In GDIHashtable, there is a static field GDIHashtable::BatchDestructionManager manager, which is initialized in GDIHashtable.cpp.
In AwtPen, there is a static field GDIHashtable cache, which is initialized in awt_Pen.cpp.
The GDIHashtable constructor calls manager.add(this).
For this to work, the manager must have been initialized prior to the AwtPen. However, the order of which static initializers are run between different compilation units are not well-defined, and we've just been lucky so far that it works.
This problem is known as the "Static Initialization Order Fiasco", see e.g. https://en.cppreference.com/w/cpp/language/siof
- blocks
-
JDK-8346377 Properly support static builds for Windows
-
- Resolved
-
- links to
-
Commit(master) openjdk/jdk/03821d97
-
Review(master) openjdk/jdk/22736