Dangerous Static Locals

Chromium style's rules regarding static and global variables make the following idiom attractive:

// This is
// * thread-safe (since C++11). Initialization happens at most once.
// * compliant with Chromium style, as destructor never runs.
NonTrivialFoo& GetFoo() {
  static base::NoDestructor<NonTrivialFoo> local;
  return *local;
}

However, the Windows C Runtime (CRT) forces the PartitionAlloc team to use this idiom with great care. This is because initializing a (nontrivial) function-local static object requires taking a lock (entering a critical section).

Windows CRT initialization is intercepted by PartitionAlloc, which attempts to initialize a function-local static, which causes re-entry into the uninitialized Windows CRT, forcing a crash.

Therefore, it's imperative that control flow never passes into initializing a static local before Windows CRT is fully initialized.

In particular, PartitionAlloc initialization during the first allocation must not use these static values.
constinit and constexpr static locals are exempt from this rule. Since they are initialized by the compiler, there's no dangerous interaction with Windows CRT.

Useful Reference Material

N.B. the first few items in this list (allocator shim and ThreadCache) demonstrate successful workarounds for this puzzle.

  1. These Google-internal slides describe the time we hit this when implementing PartitionAlloc-Everywhere.

  2. This bug was the background for the slides above and additionally chronicles other function-local statics rooted out to get PA-E working on Windows.

  3. We hit this again in 2020 in ThreadCache initialization.

  4. We hit this again in 2022 in attempting to change AddressPoolManager initialization. This was later fixed without using a static local.

  5. We hit this again in 2024 in trying to set up a freelist experiment.