A while ago setjmp/longjmp in mingw-w64 was known to be broken (http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html).
We have a legacy code that we used to run on 32 bit Linux and 32 bit Windows, which (still) works fine. 64-bit Linux version also works fine, but 64 bit Windows version breaks down after first longjmp back to setjmp location.
I get segfault somewhere in msvcrt!_setjmpex,msvcrt!RtlUnwindEx.
I have looked into code and initially I can't notice any violations of rules defined for setjmp/longjmp by C (99/11) standards in our code. The workaround described above ("use gcc builtins") also does not work for me.
I have trouble creating minimal reproducible example. Example works. Full code not. Of course I can start removing functionality from full source code, but that is not a simple task.
So, the question here is basically, is setjmp/longjmp in mingw-w64 known to (still) be broken?
Yes, it looks setjmp/longjmp still breaks down for some code compiled with x86_64-w64-mingw32 compiler. It works for simpler testcase, I tried to reproduce an issue with. So if you bump into this longjmp/setjmp issue try to use __builtin_setjmp and __builtin_longjmp instead (as explained here).
My mistake was redefining longjmp/setjmp macros, so I could choose which version to use by simple define, but missing to do this everywhere. This caused compiled program to use both builtin and library versions, which are not compatible.