runtime/race: apply LLVM zero-initialization fix

Upstream TSAN had bug that could result in use of uninitialized memory
on Go threads that don't have any TSAN events. For example, if the
thread only ever runs the GC.

This bug was fixed upstream in
cdfdb06c91.
In https://go.dev/issue/78059 we have reports of actual Go crashes due
to this bug.

Update the prebuilt race sysos to incorporate this fix. The fix is
applied as a single patch on top of the existing LLVM revisions to
minimize risk of this CL, making it safe to backport. A later CL can
update to a newer version of LLVM.

Note that all of the patch files are identical. CL 756620 makes
racebuild add a unique patch file for each architecture in the event
that some arches need distinct patches.

linux-loong64 failed race.bash when building the new syso, though they
were just timeouts, perhaps from a slow builder.

linux-riscv64 is not updated because its builder is too slow
(https://go.dev/issue/78258).

linux-ppc64le is not updated because its builder is missing curl
(https://go.dev/issue/78210).

openbsd-amd64 is not updated because its builder is missing unzip
(https://go.dev/issue/78212).

netbsd-amd64 is not updated because it does not have a LUCI builder
(https://go.dev/issue/61121).

Fixes #78059.

Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-race,gotip-darwin-arm64-race,gotip-darwin-amd64-race,gotip-freebsd-amd64-race,gotip-windows-amd64-race,gotip-linux-s390x-race,gotip-linux-arm64-race,gotip-linux-loong64
Change-Id: I5404cb88af9d86b56b385801f8a9ed106a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/757521
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>

src/runtime/race/README

@@ -4,16 +4,16 @@ the LLVM project (https://github.com/llvm/llvm-project/tree/main/compiler-rt).
 
 To update the .syso files use golang.org/x/build/cmd/racebuild.
 
-internal/amd64v1/race_darwin.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
-internal/amd64v1/race_freebsd.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
-internal/amd64v1/race_linux.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
+internal/amd64v1/race_darwin.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch internal/amd64v1/race_darwin.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
+internal/amd64v1/race_freebsd.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch internal/amd64v1/race_freebsd.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
+internal/amd64v1/race_linux.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch internal/amd64v1/race_linux.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
 internal/amd64v1/race_netbsd.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
 internal/amd64v1/race_openbsd.syso built with LLVM fcf6ae2f070eba73074b6ec8d8281e54d29dbeeb and Go 8f2db14cd35bbd674cb2988a508306de6655e425.
-internal/amd64v1/race_windows.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
-internal/amd64v3/race_linux.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
-race_darwin_arm64.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
-race_linux_arm64.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
-race_linux_loong64.syso built with LLVM 83fe85115da9dc25fa270d2ea8140113c8d49670 and Go 037112464b4439571b45536de9ebe4bc9e10ecb7.
+internal/amd64v1/race_windows.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch internal/amd64v1/race_windows.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
+internal/amd64v3/race_linux.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch internal/amd64v3/race_linux.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
+race_darwin_arm64.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch race_darwin_arm64.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
+race_linux_arm64.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch race_linux_arm64.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
+race_linux_loong64.syso built with LLVM 83fe85115da9dc25fa270d2ea8140113c8d49670 with patch race_linux_loong64.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.
 race_linux_ppc64le.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
 race_linux_riscv64.syso built with LLVM c3c24be13f7928460ca1e2fe613a1146c868854e and Go a21249436b6e1fd47356361d53dc053bbc074f90.
-race_linux_s390x.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 and Go e7d582b55dda36e76ce4d0ce770139ca0915b7c5.
+race_linux_s390x.syso built with LLVM 51bfeff0e4b0757ff773da6882f4d538996c9b04 with patch race_linux_s390x.patch and Go a61fd428974822a8c57a2b2840fc237e6711b24d.

src/runtime/race/internal/amd64v1/race_darwin.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/internal/amd64v1/race_freebsd.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/internal/amd64v1/race_linux.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/internal/amd64v1/race_windows.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/internal/amd64v3/race_linux.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/race_darwin_arm64.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/race_linux_arm64.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/race_linux_loong64.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.

src/runtime/race/race_linux_s390x.patch

@@ -0,0 +1,63 @@
+From cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca Mon Sep 17 00:00:00 2001
+From: Michael Pratt <michael@prattmic.com>
+Date: Fri, 12 Dec 2025 16:31:44 +1100
+Subject: [PATCH] [TSan] Zero-initialize Trace.local_head
+
+Trace.local_head is currently uninitialized when Trace is created. It is
+first initialized when the first event is added to the trace, via the
+first call to TraceSwitchPartImpl.
+
+However, ThreadContext::OnFinished uses local_head, assuming that it is
+initialized. If it has not been initialized, we have undefined behavior,
+likely crashing if the contents are garbage. The allocator (Alloc)
+reuses previously allocations, so the contents of the uninitialized
+memory are arbitrary.
+
+In a C/C++ TSAN binary it is likely very difficult for a thread to start
+and exit without a single event inbetween. For Go programs, code running
+in the Go runtime itself is not TSan-instrumented, so goroutines that
+exclusively run runtime code (such as GC workers) can quite reasonably
+have no TSan events.
+
+The addition of such a goroutine to the Go test.c is sufficient to
+trigger this case, though for reliable failure (segfault) I've found it
+necessary to poison the ThreadContext allocation like so:
+
+(Example patch redacted because patch tries to apply this as a real
+patch. See full commit at
+https://github.com/llvm/llvm-project/commit/cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca).
+
+The fix is trivial: local_head should be zero-initialized.
+---
+ compiler-rt/lib/tsan/go/test.c        | 4 ++++
+ compiler-rt/lib/tsan/rtl/tsan_trace.h | 2 +-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/compiler-rt/lib/tsan/go/test.c b/compiler-rt/lib/tsan/go/test.c
+index d328ab1b331d7..fcd396227a4ab 100644
+--- a/compiler-rt/lib/tsan/go/test.c
++++ b/compiler-rt/lib/tsan/go/test.c
+@@ -91,6 +91,10 @@ int main(void) {
+   __tsan_go_start(thr0, &thr1, (char*)&barfoo + 1);
+   void *thr2 = 0;
+   __tsan_go_start(thr0, &thr2, (char*)&barfoo + 1);
++  // Goroutine that exits without a single event.
++  void *thr3 = 0;
++  __tsan_go_start(thr0, &thr3, (char*)&barfoo + 1);
++  __tsan_go_end(thr3);
+   __tsan_func_exit(thr0);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+   __tsan_func_enter(thr1, (char*)&foobar + 1);
+diff --git a/compiler-rt/lib/tsan/rtl/tsan_trace.h b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+index 01bb7b34f43a2..1e791ff765fec 100644
+--- a/compiler-rt/lib/tsan/rtl/tsan_trace.h
++++ b/compiler-rt/lib/tsan/rtl/tsan_trace.h
+@@ -190,7 +190,7 @@ struct Trace {
+   Mutex mtx;
+   IList<TraceHeader, &TraceHeader::trace_parts, TracePart> parts;
+   // First node non-queued into ctx->trace_part_recycle.
+-  TracePart* local_head;
++  TracePart* local_head = nullptr;
+   // Final position in the last part for finished threads.
+   Event* final_pos = nullptr;
+   // Number of trace parts allocated on behalf of this trace specifically.