On Tue, 3 Aug 2021, Martin Storsjö wrote: > On Mon, 2 Aug 2021, Jeremy Drake via Mingw-w64-public wrote: > > > Ruby was running into a crash calling longjmp on a jmp_buf obtained by > > calling setjmp from a function that had previously called alloca. This > > was resulting in mingw_getsp returning the *current* SP rather than the > > "frame address"/"base pointer" for the frame. This caused longjmp to > > raise STATUS_BAD_STACK from RtlUnwindEx. > > > LGTM, thanks, pushed it. > > Yes, mingw_getsp() is only a rough estimate of the right value. It's odd > though how it seems to kinda work in many cases even though it isn't exactly > right, I wonder in which cases the windows unwind implementation cares about > the exact vs approximate value of it... > > // Martin >
While debugging this, noticed ruby seems to make *extensive* use of setjmp/longjmp. Originally it was trying to use __builtin_setjmp but that was crashing around the setjmp call (maybe clang's __builtin_setjmp wants a different size of jmp_buf?). I switched to using setjmp/longjmp from mingw-w64, and that mostly worked (well enough to build ruby itself), but crashed when trying to install gems, apparently because ruby threads were involved (the code in question alloca'd ruby's thread stack, set a thread "root" setjmp, and then called the thread proc). Based on what I read about STATUS_BAD_STACK, it means that either the value was not in the range of the stack, or was not "properly aligned". So most likely it didn't satisfy whatever alignment check RtlUnwindEx was doing. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
