-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception handling segfaults in the msys2/mingw64 build on Windows #16
Comments
This was previously reported by Jiri Spitz as BB Issue #10, and there's a related mailing list thread from 2013. As suggested by Jiri, about the simplest way to reproduce the issue is to run this in the interpreter:
|
Just for the record, the root cause seems to be that mingw64 uses SJLJ itself in order to implement C++ exceptions, which of course gets in the way of Pure's own use of SJLJ. This is discussed at length in the aforementioned ticket and ml conversation. |
Looks like using |
Fixed in rev. 088b875. |
Still segfaults (at random) when running (gdb) bt
#0 0x00007ff8db824faf in ntdll!RtlpNtMakeTemporaryKey ()
from C:\Windows\SYSTEM32\ntdll.dll
#1 0x00007ff8db7e6d07 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#2 0x00007ff8db823ebd in ntdll!RtlpNtMakeTemporaryKey ()
from C:\Windows\SYSTEM32\ntdll.dll
#3 0x00007ff8db7d53ac in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#4 0x00007ff8db746a99 in ntdll!RtlFreeHeap ()
from C:\Windows\SYSTEM32\ntdll.dll
#5 0x00007ff8db4e984c in msvcrt!free () from C:\Windows\System32\msvcrt.dll
#6 0x000000000015ce57 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?) |
msys2/mingw32 works all right. Failed tests with the mingw64 build:
These tests all seem to involve unhandled exceptions in some way, which then makes the interpreter crash and burn with a segfault. E.g., test011.pure is expected to throw an exception at line 2:
But instead it segfaults there. So it seems that our way of implementing exceptions using longjmp doesn't fly with mingw64. It works everywhere else, so this is likely some peculiarity in the 64 bit Windows ABI.
The text was updated successfully, but these errors were encountered: