TASK-209191 block global trace while inheriting thread data

[balupillai]

Note

Medium Risk
Touches low-level GC/thread synchronization; incorrect locking or missed unblock paths could introduce deadlocks or GC stalls under contention.

Overview
Ensures luaC_inherit_thread is thread-safe against concurrent global GC by locking the reclaimed thread during heap transfer and blocking the collector (via block_collector/unblock_collector) while holding the all_threads lock.

This reduces contention/races between global trace and thread reclamation by preventing global tracing from observing partially-moved heap state, while preserving existing delayed-inheritance test behavior.

^{Written by Cursor Bugbot for commit a21ce84. This will update automatically on new commits. Configure here.}

[Copilot]

Pull request overview

This PR aims to prevent the global tracing GC from running while a thread’s heap/object data is being inherited into another thread, by adding an explicit collector barrier around the inheritance operation.

Changes:

• Add per-OS-thread state lookup in luaC_inherit_thread.
• Block the collector before inheriting a thread’s heap contents and unblock afterward.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Double-locking th causes deadlock with existing callers

High Severity

The newly added lua_lock(th) inside luaC_inherit_thread double-locks th because at least two call sites already hold that lock. In reclaim_object (lgc.c), the caller does lua_lock(th) before calling luaC_inherit_thread(L, th). In lua_delrefthread (lapi.c), lua_lock(L) is called on the source thread which becomes the th parameter. If lua_lock is a non-recursive mutex, this will deadlock.

Additional Locations (1)

• src/lgc.c#L1727-L1730