test: #249 + #253

Sjors commented at 8:58 am on March 13, 2026: member

Testing the race condition fixes in #249 against the Bitcoin Core CI jobs added in #253.

test: worker thread destroyed before it is initialized

Add test for race condition in makeThread that can currently trigger segfaults
as reported:

https://github.com/bitcoin/bitcoin/issues/34711
https://github.com/bitcoin/bitcoin/issues/34756

The test currently crashes and will be fixed in the next commit.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>

git-bisect-skip: yes

88cacd4239

race fix: worker thread destroyed before it is initialized

This fixes a race condition in makeThread that can currently trigger segfaults
as reported:

https://github.com/bitcoin/bitcoin/issues/34711
https://github.com/bitcoin/bitcoin/issues/34756

The bug can be reproduced by running the unit test added in the previous commit
or by calling makeThread and immediately disconnecting or destroying the
returned thread. The bug is not new and has existed since makeThread was
implemented, but it was found due to a new functional test in bitcoin core and
with antithesis testing (see details in linked issues).

The fix was originally posted in
https://github.com/bitcoin/bitcoin/issues/34711#issuecomment-3986380070

f09731e242

test: getParams() called after request cancel

Add test for disconnect race condition in the mp.Context PassField() overload
that can currently trigger segfaults as reported in
https://github.com/bitcoin/bitcoin/issues/34777.

The test currently crashes and will be fixed in the next commit.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>

git-bisect-skip: yes

75c5425173

race fix: getParams() called after request cancel

This fixes a race condition in the mp.Context PassField() overload which is
used to execute async requests, that can currently trigger segfaults as
reported in https://github.com/bitcoin/bitcoin/issues/34777 when it calls
call_context.getParams() after a disconnect.

The bug can be reproduced by running the unit test added in the previous commit
and was also seen in antithesis (see details in linked issue), but should be
unlikely to happen normally because PassField checks for cancellation and
returns early before actually using the getParams() result.

This bug was introduced commit in 0174450ca2e95a4bd1f22e4fd38d83b1d432ac1f
which started to cancel requests on disconnects. Before that commit, requests
would continue to execute after a disconnect and it was ok to call getParams().

This fix was originally posted in
https://github.com/bitcoin/bitcoin/issues/34777#issuecomment-4024285314

e69b6bf3f4

test: m_on_cancel called after request finishes

Add test disconnect for race condition in the mp.Context PassField() overload
reported in https://github.com/bitcoin/bitcoin/issues/34782.

The test crashes currently with AddressSanitizer, but will be fixed in the next
commit. It's also possible to reproduce the bug without AddressSanitizer by
adding an assert:

```diff
--- a/include/mp/type-context.h
+++ b/include/mp/type-context.h
@@ -101,2 +101,3 @@ auto PassField(Priority<1>, TypeList<>, ServerContext& server_context, const Fn&
                     server_context.cancel_lock = &cancel_lock;
+                    KJ_DEFER(server_context.cancel_lock = nullptr);
                     server.m_context.loop->sync([&] {
@@ -111,2 +112,3 @@ auto PassField(Priority<1>, TypeList<>, ServerContext& server_context, const Fn&
                             MP_LOG(*server.m_context.loop, Log::Info) << "IPC server request #" << req << " canceled while executing.";
+                            assert(server_context.cancel_lock);
                             // Lock cancel_mutex here to block the event loop
```

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>

git-bisect-skip: yes

846a43aafb

race fix: m_on_cancel called after request finishes

This fixes a race condition in the mp.Context PassField() overload which is
used to execute async requests, that can currently trigger segfaults as
reported in https://github.com/bitcoin/bitcoin/issues/34782 when a cancellation
happens after the request executes but before it returns.

The bug can be reproduced by running the unit test added in the previous commit
and was also seen in antithesis (see details in linked issue), but should be
unlikely to happen normally because the cancellation would have to happen in a
very short window for there to be a problem.

This bug was introduced commit in 0174450ca2e95a4bd1f22e4fd38d83b1d432ac1f
which started to cancel requests on disconnects. Before that commit a
cancellation callback was not present.

This fix was originally posted in
https://github.com/bitcoin/bitcoin/issues/34782#issuecomment-4033169085

2fb97e8cca

DrahtBot commented at 8:59 am on March 13, 2026: none

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

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

neccessary -> necessary [spelling error in comment: “Sleep is neccessary…” -> “Sleep is necessary…”]
after it execute an async requests -> after it executes an async request [subject-verb and number agreement: “after it execute an async requests” -> “after it executes an async request”]

2026-03-13 09:35:59

ci: add Bitcoin Core IPC tests (ASan + macOS) b78aa4a345

ci: add TSan job with instrumented libc++ db756c8440

ci: set Bitcoin Core CI test repetition 3dd6d57047

Sjors force-pushed on Mar 13, 2026

Sjors closed this on Mar 24, 2026

test: #249 + #253 #257

Reviews

LLM Linter (✨ experimental)