Open agraef opened 6 years ago
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:
[1,2]!5;
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 __builtin_setjmp
and __builtin_longjmp
instead of the msvc versions of setjmp/longjmp should fix this, cf. http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html. Currently giving this a try.
Fixed in rev. 088b875ff13c29020eeb94b9690243f58c7771f1.
Still segfaults (at random) when running pure test011.pure
from bash. Unfortunately, the gdb backtrace isn't particularly helpful:
(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.