Noticed a mail re: breakage related to changing the defn. of RESERVED_C_STACK_BYTES. Here's a little bit of info re: the underlying issue, in case this isn't known. Simon Marlow writes: > Aha! *slaps forehead* It's just dawned on me, and Julian & I verified that > the problem is indeed this: > > RESERVED_C_STACK_BYTES has recently increased to about 8k > (2 pages), and while this works on sane^H^H^H^H Unix-like operating > systems apparently the NT page faulter only lets you grow the stack a page > at a time. And alloca() probably writes to each page in turn to get around the > restriction. Ok, I've now committed a fix for this. Thanks for tracking it down. Not quite right, but close. By default, each new Win32 thread starts off with one page(4K, probably) worth of stack committed to the pagefile (Win32 VM makes the distinction between allocated and committed virtual memory.) If you move the stack pointer beyond the committed region, an exception is raised telling you that you touched guarded memory. If haven't run past the end of the stack, the toplevel structured exception handler will then commit more memory to the pagefile. Why it doesn't catch the exception in your case, I do not know - maybe cygwin fails to set it up correctly? VC++'s link.exe provides an option for changing the stack commit increment/delta (The /STACK option) I'm not sure if GNU ld provides the same. --sigbjorn
