#1070 has revealed a slight flaw in#938 in that the native code stack overflow test is failing. My investigations have determined that the most likely cause of this is thatwin32_alt_stack declared inbyterun/win32.c is in certain circumstances not large enough.

This GPR is arriving in two bits, just so that I can get more AppVeyor logs - the first commit being added alters the stack overflow test to record backtraces for the second run. On AppVeyor and on my Windows 10 1703 machines, this is sufficient to cause the native code executable to segfault. Interestingly, on Windows Server 2016 instances running on Azure and also on my Windows 10 1511 box, the same binary works successfully. I'm making slightly hand-wavy assertions that this is a mixture of ASLR and possibly code injecty things (Windows Defender et al) causing this. win32_alt_stack does not have a guard page, so I believe I'm correct that if it overruns, we're just looking at chaos - hence the strange fact that#1070 appears to have triggered it. On machines where it fails, it seems to fail with both msvc32 and msvc64 but not with mingw32 or mingw64. I've been testing VS 2015 and VS 2017, so I'm guessing it's just down to the different runtimes possibly needing a teensy bit more stack between the exception handler completing andcaml_raise_exception restoring the old one.

As far as I can tell, just doubling the size ofwin32_alt_stack is enough to mitigate this.