Bug 13105 – Stack overflow in Fibers running druntime unittests

When I build github master and run the druntime unittests for Win32, I get a stack overflow when an exception is thrown from within a fiber. thread.d, line 4719: unittest { enum MSG = "Test message."; try { (new Fiber({ throw new Exception( MSG ); })).call(); assert( false, "Expected rethrown exception." ); } catch( Throwable t ) { assert( t.msg == MSG ); } } It crashes with this stack: KernelBase.dll!_LoadLibraryExW@12() + 0xc6 bytes kernel32.dll!_LoadLibraryW@4() + 0x12 bytes dbghelp.dll!LoadDLL() + 0xe9 bytes dbghelp.dll!symsrvLoadLib() + 0x43 bytes dbghelp.dll!AddPath() + 0x78 bytes dbghelp.dll!symsrvTest() + 0x4e bytes dbghelp.dll!diaLocatePdb() + 0x508 bytes dbghelp.dll!diaGetPdb() + 0x1b7 bytes dbghelp.dll!GetDebugData() + 0x23b bytes dbghelp.dll!modload() + 0x287 bytes dbghelp.dll!LoadSymbols() + 0x352 bytes dbghelp.dll!FindModule() + 0x1ab bytes dbghelp.dll!_SymFunctionTableAccess64AccessRoutines@20() + 0x71 bytes dbghelp.dll!_SymFunctionTableAccess64@12() + 0x17 bytes dbghelp.dll!FunctionTableAccessRoutineLocal() + 0x13 bytes dbghelp.dll!DbhStackServices::GetFunctionEntry() + 0x23 bytes dbghelp.dll!DbsX86StackUnwinder::SearchForReturnAddress() + 0x3f0 bytes dbghelp.dll!DbsX86StackUnwinder::FrameInfoUnwind() + 0x3ec bytes dbghelp.dll!DbsX86StackUnwinder::Unwind() + 0x161 bytes dbghelp.dll!DbsStackUnwinder::DbhUnwind() + 0xcd bytes dbghelp.dll!PickX86Walk() + 0x153 bytes dbghelp.dll!_StackWalkEx@40() + 0x32e bytes dbghelp.dll!_StackWalk64@36() + 0x89 bytes unittest.exe!_D4core3sys7windows10stacktrace10StackTrace11traceNoSyncFkPS4core3sys7windows7windows7CONTEXTZAm() + 0x298 bytes unittest.exe!_D4core3sys7windows10stacktre10Sင???() + 0x2c bytes unittest.exe!_D4core6thread18__unittestL4719_95FZ9__lambda1FNaNfZv() + 0x39 bytes I guess it would not happen if it won't be the first stracktrace generated which has to load additional DLLs. I also get a stack overflow with the fiber unittests for Win64 if I create a druntime debug build and a collection runs from within the fiber. The recursive calls for GC scanning are too deep then (50).

So how about increasing the default fiber stack size to 64kB - GUARD_PAGE. At least on Windows that wouldn't even consume more address space because of the 64kB granularity of VirtualAlloc.

Is this still a problem?

> Is this still a problem? The affected tests are currently disabled because of issue 13821. If I enable them I don't see any problems, though my system might have changed in the meantime. > I also get a stack overflow with the fiber unittests for Win64 > if I create a druntime debug build and a collection runs from within > the fiber. The recursive calls for GC scanning are too deep then (50). This is gone aswell as the GC doesn't recurse anymore. > So how about increasing the default fiber stack size to 64kB - GUARD_PAGE That sounds good. If memory resources are low or you want a lot of fibers, multiple fibers could rather share the same 64k block, though.