File: static_local_danger.md

package info (click to toggle)
chromium 139.0.7258.127-1
  • links: PTS, VCS
  • area: main
  • in suites:
  • size: 6,122,068 kB
  • sloc: cpp: 35,100,771; ansic: 7,163,530; javascript: 4,103,002; python: 1,436,920; asm: 946,517; xml: 746,709; pascal: 187,653; perl: 88,691; sh: 88,436; objc: 79,953; sql: 51,488; cs: 44,583; fortran: 24,137; makefile: 22,147; tcl: 15,277; php: 13,980; yacc: 8,984; ruby: 7,485; awk: 3,720; lisp: 3,096; lex: 1,327; ada: 727; jsp: 228; sed: 36
file content (71 lines) | stat: -rw-r--r-- 2,754 bytes parent folder | download | duplicates (9)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
# Dangerous Static Locals

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

```c++
// 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 a
  ttempts to initialize a function-local static, which causes re-entry i
  nto the uninitialized Windows CRT, forcing a c
  rash.](./src/partition_alloc/dot/windows_crt_static_local_ouroboros.png)

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

***aside
In particular, PartitionAlloc initialization during the first allocation
must not use these static values.
***

*** note
`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][google-internal-pae-talk] describe
    the time we hit this when implementing PartitionAlloc-Everywhere.

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

1.  [We hit this again in 2020][thread-cache-issue]
    in `ThreadCache` initialization.

1.  [We hit this again in 2022][address-pool-manager-issue] in
    attempting to change `AddressPoolManager` initialization. This was
    later [fixed without using a
    static local][address-pool-manager-workaround].

1.  [We hit this again in 2024][freelist-dispatcher-issue] in
    trying to set up a freelist experiment.


[static-and-global]: https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
[google-internal-pae-talk]: https://docs.google.com/presentation/d/1fAgGNxaWtRbrTOJrNS9QG3nI6_c6efdW4RuzNtmKS1E/edit#slide=id.gdddf5d4640_0_364
[pae-win-bug]: https://issues.chromium.org/u/1/issues/40148130
[thread-cache-issue]: https://crrev.com/c/2474857
[address-pool-manager-issue]: https://crrev.com/c/3614389
[address-pool-manager-workaround]: https://crrev.com/c/3642766
[freelist-dispatcher-issue]: https://crbug.com/336007395