mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-11-10 09:13:53 +08:00
Martin Vogel
5f2c146866
Two Windows tests needed the startup thread to be observed HOLDING the startup lock, and looked for it by polling the lock for BUSY up to 200 times. That state has no lower bound: whenever the rendezvous handoff does not block, acquire -> handoff -> release completes in microseconds, so the window can close between two polls and startup_observed asserts on a coin flip. This blocked release run 30374135923 on test-windows (windows-2025, CLANG64, x86_64). Budget-tuning the poll was tried and rejected -- a wider budget only lowers the failure rate, and a transient window is never a fixed test. Instead the production path exposes a gate that fires once the startup lock is held and before the handoff runs, matching the hook pattern already used for POSIX publication. The test parks the startup thread there and releases it when it is ready, so the interleaving is pinned by construction. The acquired flag is monotonic, so the observation cannot be missed; the remaining bound only catches a thread that never started at all. The gate is inert unless a test installs it. Also fixes an unrelated use-after-free this exposed. ipc_forever_wait_server closed the connection and NULLed it from the server thread, while the test was about to call cbm_daemon_ipc_connection_interrupt on the pointer it had already loaded -- and receive_frame can return on its own before that call lands. It crashed roughly one Windows run in five, independent of the change above. Ownership now stays with the test, which closes after joining, so interrupt can only ever see a live connection. Verified on real Windows: 5 consecutive daemon_ipc runs, no failure and no crash. macOS 46 passed x5 under ASan/UBSan; Linux 6606 passed, 0 failed. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>