Skip to content
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

Open
agraef opened this issue Feb 23, 2018 · 5 comments
Open

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

agraef opened this issue Feb 23, 2018 · 5 comments
Assignees
Labels

Comments

@agraef
Copy link
Owner

agraef commented Feb 23, 2018

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 agraef added the bug label Feb 23, 2018
@agraef agraef self-assigned this Feb 23, 2018
@agraef
Copy link
Owner Author

agraef commented Feb 23, 2018

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
Copy link
Owner Author

agraef commented Feb 23, 2018

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
Copy link
Owner Author

agraef commented Feb 23, 2018

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
Copy link
Owner Author

agraef commented Feb 23, 2018

Fixed in rev. 088b875.

@agraef agraef closed this as completed Feb 23, 2018
@agraef
Copy link
Owner Author

agraef commented Feb 24, 2018

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

@agraef agraef reopened this Feb 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant