A released weak-reference target stays alive on the Windows CI runners #367

GenerationalWeakRefLifecycle keeps 256 old targets and their weak references, releases the targets, runs three full collections and checks that every reference is cleared. On the Windows 64 CI runners, exactly one is not: reference 31.

full collection clears released old targets: false (kept 31)

It fails this way on Haxe 4.3.7 and Haxe 5.0.0-preview.1, both on Windows 64 with HXCPP_GC_GENERATIONAL, and it is always reference 31. The test passes on Linux 64, Linux 32, macOS arm64 and macOS Intel, and on a local Windows 64 build with MSVC 19.44, run directly or as a child process the way the regression runner starts it.

It is not caused by the generational collector changes in batch 6-g. The same test on main at f81151a2adfdae7b7335e0175739c57a226980f4, with no other change, fails the same way on the Windows 64 jobs: https://github.com/openfl/libhxcpp/actions/runs/40192659495

The targets are built, checked and released on joined worker threads, so that no stale value on the main thread's stack decides their liveness. The likeliest cause is still a pointer to that one object left where the collector scans conservatively on those runners: a thread's stack or saved registers, or a pooled allocator's. But one object kept for good on one platform could also be a real retention, so it needs tracing rather than assuming.

To do:

• Find what keeps the object alive on a Windows runner, for example with a census of the roots that reach it.
• Fix the retention if it is one, or make the test independent of it if it is the conservative scan.
• Restore the check on Windows: the test holds it there until then, and names this issue.

Found by test/regression/GenerationalWeakRefLifecycle, added for #314.