不久前，已知mingw-w64中的setjmp/longjmp已损坏(http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html)。
我们有一个以前在32位Linux和32位Windows上运行的遗留代码，它(仍然(运行良好。64位的Linux版本也运行良好，但64位的Windows版本在第一次将jmp返回到setjmp位置后就会崩溃。
我在msvcrt的某个地方找到了segfault_setjmpex，msvcrt！RtlUnwindEx。
我已经研究了代码，最初我没有注意到我们的代码中有任何违反C(99/11(标准为setjmp/longjmp定义的规则的行为。上面描述的解决方法("使用gcc内置"(也不适用于我
我很难创建最小的可复制示例。示例起作用。没有完整的代码。当然，我可以开始从完整的源代码中删除功能，但这不是一项简单的任务。
所以，这里的问题基本上是，mingw-w64中的setjmp/longjmp是否已知(仍然(被破坏？
是的，对于一些使用x86_64-w64-mingw32编译器编译的代码，setjmp/longjmp看起来仍然会崩溃。它适用于更简单的测试用例，我试图用它重现一个问题。因此，如果您遇到这个longjmp/setjmp问题，请尝试使用__builtin_setjmp和__builtin-longjmp(如这里所解释的(。
我的错误是重新定义longjmp/setjmp宏，所以我可以通过简单的定义来选择使用哪个版本，但在任何地方都没有这样做。这导致编译后的程序同时使用不兼容的内置版本和库版本。