[SizzleUnrlsd]

Refs #243

Summary

On Windows, __ct_munmap dropped the freed record of a page with the allocation table's lock (ct_alloc_lock) held, outside a runtime scope. Erasing the record frees a node of the table. When that release reaches the runtime's entry points, as through the copies of the library's inline functions that an instrumented module compiles (#197), the entry point opens a scope and takes ct_alloc_lock again, from the thread that holds it: SRW locks are not recursive, and the unmap never returns.

__ct_munmap now runs in a runtime scope (CtRuntimeScope), as ct_release_tracked_pointer and ct_autofree_impl already do around the same releases. The entry point that the node's release reaches sees the runtime's own work and passes it on without taking the lock. The diff to the runtime is the scope and its comment, in src/runtime/windows/ct_runtime_alloc.cpp.

The POSIX runtime does not take this path: its table marks a dropped record as a tombstone in place and frees nothing.

Evidence

The tests ran in the four Windows jobs of LLVM versions (LLVM 19, 20, 22, 23), on main and on this branch.

Run	Branch, head	Sources	Windows jobs
42100512865	probe/243-red, 5cc839e	main (c11f8a5) with the test DLL's new function and the two tests below, without the fix	246/247 in each job: ADllWhoseOperatorDeleteFreesThroughItsCopyUnmapsAPage fails with exit status 7, after 20.01 to 20.02 seconds; the control passes.
42100593457	this branch, fef03fd	this branch	247/247 in each job; the 15 jobs of LLVM versions pass, and so do Build, clang-format, license-compliance and the commit conventions.

#243's first probe (probe/munmap-forget-lock, 381e187, run 41341737799) gave the same result on a head of #242.

Tests

The allocating test DLL gains ct_allocating_library_map_and_unmap, which maps a page through its copy of the runtime (__ct_mmap), which records it, and unmaps it (__ct_munmap), which drops the page's record. Two death tests load a DLL in a child process that starts its watchdog first (startWatchdog(), exit status 7 after 20 seconds) and exit with 0 once the unmap returned:

Test	DLL	What it checks
ADllThatMapsAPageThroughItsCopyUnmapsIt	ct_allocating_library, with the C++ library's operators	The control: the page is mapped, recorded, unmapped and its record dropped.
ADllWhoseOperatorDeleteFreesThroughItsCopyUnmapsAPage	ct_new_delete_through_runtime_library, whose operators new and delete go through the copy, as a model of #197	The node that dropping the record frees comes back to the copy's entry points with the table's lock held, and the unmap still returns.

Limits

• Whether an instrumented program reaches this path is not established: it needs the linker to keep, for the runtime, the instrumented copy of the library's deallocation, and a program that unmaps a mapping the runtime recorded. The test DLL forces both, as Windows runtime: __ct_munmap drops a freed record under the table's lock outside a runtime scope #243's probe did.