libunwind (SEH on MinGW) : segfault during unwinding

[614eaf53-7ecd-4c4f-a941-40bf78db1486]

Bugzilla Link	39935
Resolution	FIXED
Resolved on	Dec 11, 2018 01:54
Version	trunk
OS	Windows NT
Attachments	code that reproduces the problem
CC	@mstorsjo
Fixed by commit(s)	r348836

Extended Description

Hello, I originally posted this issue here : https://github.com/mstorsjo/llvm-mingw/issues/25

The attached repro gives an example which causes a segfault (with the llvm-mingw toolchain) The build.sh script will build a code and launch the program in the case which causes the problem (segfault while unwinding). There are a bunch of files but the actual stack trace is very short and only spans two files (main.cpp and parser/sourcereader.cpp):

Thread 1 hit Catchpoint 1 (exception thrown), 0x0000000140010a90 in __cxa_throw () (gdb) bt

​0 0x0000000140010a90 in __cxa_throw ()

​1 0x000000014000657d in SourceReader::parseLocal (this=,

fname=<optimized out>) at C:/dev/repro-except/parser\sourcereader.cpp:93

​2 0x0000000140006235 in SourceReader::parseFile (this=,

fname=<optimized out>) at C:/dev/repro-except/parser\sourcereader.cpp:84

​3 0x000000014000c4fa in compileFaustFactory (argc=,

argv=0x524250, name=<optimized out>, dsp_content=<optimized out>,
error_msg=..., generate=<optimized out>)
at C:/dev/repro-except\main.cpp:21

​4 0x000000014000c668 in main (argc=,

argv=0x140012260 <typeinfo for faustexception>)
at C:/dev/repro-except\main.cpp:33

The smallest change to the code path, for instance changing parseLocal from :

Tree SourceReader::parseLocal(const char* fname) { stringstream error;

throw faustexception("blah");
return gGlobal->gResult;

}

to

Tree SourceReader::parseLocal(const char* fname) { throw faustexception("blah"); return gGlobal->gResult; }

or removing the untaken if branch in sourcereader.cpp:79, makes the problem go away.

Also, it works at -O1, it's only starting from -O2 that it fails.

The same code works fine with clang on both linux and macos.

[mstorsjo]

This should be fixed in SVN r348836.

[mstorsjo]

The backtrace looks like this for me:

Thread 1 received signal SIGSEGV, Segmentation fault. 0x00007ffd6763820c in ntdll!RtlLookupFunctionEntry () from C:\WINDOWS\SYSTEM32\ntdll.dll (gdb) bt bt

​0 0x00007ffd6763820c in ntdll!RtlLookupFunctionEntry () from C:\WINDOWS\SYSTEM32\ntdll.dll

​1 0x00007ffd6763739c in ntdll!RtlUnwindEx () from C:\WINDOWS\SYSTEM32\ntdll.dll

​2 0x00000001800025e6 in _Unwind_Resume () from C:\code\repro-except\cross\libunwind.dll

​3 0x000000014000666d in SourceReader::parseLocal (this=, fname=)

at /home/martin/clang-nightly/x86_64-w64-mingw32/include/c++/v1/iosfwd:117

​4 0x00000001400062b5 in SourceReader::parseFile (this=, fname=)

at /home/martin/code/repro-except/parser/sourcereader.cpp:84

​5 0x000000014000c3fa in compileFaustFactory (argc=, argv=0x415d00, name=,

dsp_content=<optimized out>, error_msg=..., generate=<optimized out>)
at /home/martin/code/repro-except/main.cpp:21

​6 0x000000014000c558 in main (argc=, argv=0x0) at /home/martin/code/repro-except/main.cpp:33

[mstorsjo]

To add more context to the bug; this happens when unwinding x86_64 SEH with libunwind - if the unwinder is replaced with libgcc, unwinding works fine.

CC:ing Charles who wrote the SEH unwinder for libunwind.

Also, there's a compiled version of the repro at https://martin.st/temp/repro-except-binaries.zip. If you run "faust.exe foo.dsp", you'll get the crash. If you replace libunwind.dll with libgcc_s_seh-1.dll and retry, the crash goes away.