You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
engine_contract_tests hangs on Windows CI (zero output, timeout at 120s) #63
The new engine_contract_tests suite (DasherBridge + real engine contract tests: fresh-user-dir creation, probe-then-fetch, text-size cache, frame clamp) passes on Linux and macOS but hangs on the Windows leg — ctest kills it at the 120 s timeout with no output at all, not even doctest's version banner. Because the timeout kills the process, buffered stdout is lost, so which of the five cases hangs is unknown.
Ruled out so far:
Not the 1-hour ctest stall: bounded with a TIMEOUT property (that earlier stall was the unbounded run).
Not the debug/release CRT mix: MSVC_RUNTIME_LIBRARY MultiThreadedDLL forced (same guard as dasher_unit_tests, which runs fine) — still hangs.
Not a compile failure: the target builds on Windows (and still does — only the add_test registration is now gated to non-MSVC).
Suspects, in order:
getpid() in make_fresh_user_dir() — pulls a POSIX-ish path that may behave oddly under MSVC's UCRT (it compiled, but from where?).
std::filesystem::temp_directory_path() + create_directories under the CI sandbox.
dasher_create on a Windows temp path — the DasherCore fix: qualify tag-derived version claim; bump tarball fallback to 0.2.7 #59 family was exactly Windows-path-related; a surviving variant could block (not crash) on some path shapes. Note DasherCore v0.2.6 is pinned and the prefs selftest creates engines fine on the same runner, which weakens this.
Something in loading the GTK stack headless in a plain test exe (no xvfb-equivalent) — though dasher_unit_tests links GTK too and runs.
To debug (needs a Windows box): run the exe directly in a console (not via ctest) so stdout isn't lost on kill; attach a debugger to see where it blocks; try --test-case= filters to bisect the five cases.
CI impact today: none — the suite is registered on Linux/macOS only; Windows still builds the target so the code paths stay compiled.
Follow-up from PR #62.
The new
engine_contract_testssuite (DasherBridge + real engine contract tests: fresh-user-dir creation, probe-then-fetch, text-size cache, frame clamp) passes on Linux and macOS but hangs on the Windows leg — ctest kills it at the 120 s timeout with no output at all, not even doctest's version banner. Because the timeout kills the process, buffered stdout is lost, so which of the five cases hangs is unknown.Ruled out so far:
MSVC_RUNTIME_LIBRARY MultiThreadedDLLforced (same guard asdasher_unit_tests, which runs fine) — still hangs.add_testregistration is now gated to non-MSVC).Suspects, in order:
getpid()inmake_fresh_user_dir()— pulls a POSIX-ish path that may behave oddly under MSVC's UCRT (it compiled, but from where?).std::filesystem::temp_directory_path()+ create_directories under the CI sandbox.dasher_createon a Windows temp path — the DasherCore fix: qualify tag-derived version claim; bump tarball fallback to 0.2.7 #59 family was exactly Windows-path-related; a surviving variant could block (not crash) on some path shapes. Note DasherCore v0.2.6 is pinned and the prefs selftest creates engines fine on the same runner, which weakens this.To debug (needs a Windows box): run the exe directly in a console (not via ctest) so stdout isn't lost on kill; attach a debugger to see where it blocks; try
--test-case=filters to bisect the five cases.CI impact today: none — the suite is registered on Linux/macOS only; Windows still builds the target so the code paths stay compiled.