Per user feedback:
1. Removed T-shirt size metric from the report. The T-shirt size
convention is defined in conductor/tracks.md (lines 47, 738, 748,
790) and conductor/workflow.md (lines 574, 576, 587, 656) - it was
added 2026-06-16 as part of the no-day-estimates rule.
2. Re-investigated the actual call stack depth. The Python call chain
at crash time is only 13 frames deep. This is NOT a Python
recursion bug.
3. Measured the main thread stack via kernel32.GetCurrentThreadStackLimits.
It is 1.94 MB on this Python 3.11.6 installation. The sitecustomize
sets threading.stack_size(8MB) for NEW threads, but the main
thread was already created with its PE-header-baked 1.94MB.
4. Bumped io_pool workers to 8MB via threading.stack_size(8MB) in
sitecustomize.py. Process STILL dies with 0xC00000FD. So the
stack overflow is NOT in the io_pool worker. It is in the main
thread, running the imgui-bundle render loop.
5. The main thread is 1.94MB. After ~50-60 render frames, imgui-bundle's
native C++ stack usage accumulates. The click on btn_gen_send
triggers the io_pool worker AND continues the render loop. The
next render frame's C++ stack usage overflows the main thread's
1.94MB guard page, killing the process.
The fix is NOT about the io_pool thread stack. It is about either:
(a) reducing imgui-bundle's per-frame C++ stack usage (e.g., fix the
stale manualslop_layout.ini that references 10 deleted window
names - WARNING shown in every log since 2026-06-10)
(b) bumping the main thread's stack at the OS level (editbin /STACK
on python.exe)
(c) running the render loop in a subprocess
Capture a WER crash dump to identify the exact C-side stack frame
that overflows. Add SetUnhandledExceptionFilter via sitecustomize.py
to log the crashing thread's TEB to stderr before the process dies.
ed
aee2061a74