workaround: MinGW thread_local use-after-free in ThreadContext

[ryanofsky]

Work around mingw bug thread_local bug https://sourceforge.net/p/mingw-w64/bugs/527/ that causes failures in windows "test cross-built" CI jobs in bitcoin/bitcoin#32387 by skipping thread_local destructors in mingw.

The workaround will result in resource leaks in mingw builds, that might be noticeable if a lot of threads are created and destroyed, but should not be a significant problem in practice.

This change is just a refactoring in other builds (including MSVC) not affected by this bug.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
Stale ACK	xyzconstant, Sjors

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

• client disconnectss -> client disconnects [extra “s” is a typo]

^{2026-07-30 16:26:42}

[ryanofsky]

Updated 1243dd3 -> 1500701 (pr/win-tls.1 -> pr/win-tls.2, compare) renaming GThreadContext to CurrentThread

[xyzconstant]

In commit 1500701 "workaround: MinGW thread_local use-after-free in ThreadContext"

nit: The commit body still mentions GThreadContext() instead of CurrentThread

[xyzconstant]

Code review ACK 1500701

Compiled and ran tests on macOS. Tried to reproduce the heap corruption with a mingw-w64 cross-build run under Wine following some of the instructions in the bug report links but didn't have any success (maybe luck?).

My understanding: MinGW's machinery doesn't guarantee a safe cleanup order for thread_local variables. The idea is to skip the __cxa_thread_atexit call entirely (which registers ~ThreadContext, a non-trivial destructor to run at thread exit) so its scheduled destructor doesn't run on already-freed memory and thereby avoid heap corruption. The changes in this PR implement that by modifying the g_thread_context variable (now returned by CurrentThread()) from a value of type ThreadContext to a pointer of type ThreadContext * on MinGW. This results in only the emutls cleanup running. This frees the pointer's storage at destruction time, and the context object is, as a result, leaked.

The cost of this leakage is that exiting client threads won't release the Thread capability, which means the server threads aren't closed until the connection is closed (closing the connection destroys those OS threads).

Other target builds remain unaffected. The documentation is well-written, and it's clear to any developer why this workaround exists. This PR looks good to me.

[hebasto]

Is this specific to MSVCRT, or does it occur with UCRT as well?

[ryanofsky]

re: #318 (comment)

Is this specific to MSVCRT, or does it occur with UCRT as well?

I don't think it has anything do to with the C runtime, although agent noted it did not see this error under UCRT builds for some reason (see "since the underlying bug is CRT-independent" comment below)

This error is pretty easy to reproduce by disabling the #ifdef __MINGW32__ workaround in bitcoin/bitcoin#32387 and seeing the cross-compiled CI job in interface_ipc_cli.py and interface_ipc_mining.py tests. You can see the ci errors looking at win-work branch pushes from Jul 22 in `https://github.com/ryanofsky/bitcoin/actions like https://github.com/ryanofsky/bitcoin/actions/runs/29931590196/job/88964021272

[Sjors]

Wrapping g_thread_context in CurrentThread(), and then dropping it entirely, is nice in general. Maybe make it a prep refactor commit(s), so the windows change is more focussed. See sjors/2026/07/mingw.

My agent also couldn't reproduce the original issue on Linux with Wine, initially not on Windows 11 either, but I'll keep trying.

I didn't verify the Windows-specific rationale, but the change itself seems simple enough is well documented.

[Sjors]

ACK 1500701

It figured it out: https://gist.github.com/Sjors/4b70c60a5d2989bf2ba4adb408d2554c

[maflcko]

Seems fine, but given that this was already fixed in mingw-w64/mingw-w64@8e06daa / 13.0.0 , I wonder if it would be easier to just build that version (or later).

This is with the background that the Ubuntu/Debian packages are already broken and possibly unmaintained, so we may want to consider self-building anyway? Ref: bitcoin/bitcoin#33593 (comment)

Either self-building directly, or using something like https://github.com/0xB10C/bitcoind-gunix/blob/v31.1/nix/win64/toolchain.nix ? Edit: mingw in guix was bumped to v13 in bitcoin/bitcoin@31eb46f

[ryanofsky]

re: #318 (comment)

mingw in guix was bumped to v13 in bitcoin/bitcoin@31eb46f

Thanks for these details. Would have to look into this more but would be nice if this is already fixed in guix builds and the workaround is unnecessary there.

I think we still might want this code change (maybe narrowed to depend on mingw version or whether the fix is present) if it is easier than self-building mingw in CI. A motivation for this change is getting
interface_ipc_cli.py and interface_ipc_mining.py tests to pass in bitcoin/bitcoin#32387 cross-compiled CI jobs

---

Rebased 1500701 -> 608d09a (pr/win-tls.2 -> pr/win-tls.3, compare) due to silent conflicts with #323

[ryanofsky]

re: #318 (comment)

Is this specific to MSVCRT, or does it occur with UCRT as well?

I don't think it has anything do to with the C runtime, although agent noted it did not see this error under UCRT builds for some reason (see "since the underlying bug is CRT-independent" comment below)

This error is pretty easy to reproduce by disabling the #ifdef __MINGW32__ workaround in bitcoin/bitcoin#32387 and seeing the cross-compiled CI job in interface_ipc_cli.py and interface_ipc_mining.py tests. You can see the ci errors looking at win-work branch pushes from Jul 22 in `https://github.com/ryanofsky/bitcoin/actions like https://github.com/ryanofsky/bitcoin/actions/runs/29931590196/job/88964021272

[maflcko]

Thanks for these details. Would have to look into this more but would be nice if this is already fixed in guix builds and the workaround is unnecessary there.

It is just a guess that this is already fixed, since I don't have Windows to test. One could check by using ubuntu:resolute in the CI config, maybe?

The general idea is that we are having problems cross-compiling with the apt system packages, so using guix or nix instead could help with that, and possibly also help with making the CI closer to the release bins, and possibly even align the cross-compile docs to produce bins identical to the ones from contrib/guix.

So trying to use a mingw from nix (possibly in combination with a apt system gcc, or so) would be interesting and could possibly fix a bunch of issues (or introduce more issues, heh).

[maflcko]

I think we still might want this code change (maybe narrowed to depend on mingw version or whether the fix is present) if it is easier than self-building mingw in CI. A motivation for this change is getting
interface_ipc_cli.py and interface_ipc_mining.py tests to pass in bitcoin/bitcoin#32387 cross-compiled CI jobs

If you want, you can merge bitcoin/bitcoin#35877 (mingw 13) into 32387, to see if it passes CI.