简体   繁体   中英

setjmp/longjmp in x86_64-w64-mingw32

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM