agraef / pure-lang

Pure programming language
https://agraef.github.io/pure-lang/
316 stars 20 forks source link

Exception handling segfaults in the msys2/mingw64 build on Windows #16

Open agraef opened 6 years ago

agraef commented 6 years ago

msys2/mingw32 works all right. Failed tests with the mingw64 build:

$ make recheck
./run-tests -f
Running tests.
test011.pure: FAILED
test015.pure: FAILED
test020.pure: FAILED
test046.pure: FAILED
test058.pure: FAILED
test060.pure: FAILED
test072.pure: FAILED
test092.pure: FAILED
make: *** [Makefile:578: recheck] Error 1

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:

> using system;
> sscanf "this" "%d";
<stdin>, line 2: unhandled exception 'scanf_error ()' while evaluating 'sscanf "this" "%d"'

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.

agraef commented 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;
agraef commented 6 years ago

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.

agraef commented 6 years ago

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.

agraef commented 6 years ago

Fixed in rev. 088b875ff13c29020eeb94b9690243f58c7771f1.

agraef commented 6 years ago

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?)