I've experienced segfaults caused by using the Throw statement.
These happen consistently on my machine when executing certain builds, but only under extremely specific conditions. For example, I've been able to consistenly produce crashes on my machine with the following code:
SuperStrict
Framework BRL.Threads
Local threads:TThread[2]
For Local i:Int = 0 Until threads.length
threads[i] = TThread.Create(TestThread, New TTestThreadData)
Next
For Local t:TThread = EachIn threads
t.Wait
Next
Type TTestThreadData
End Type
Function TestThread:Object(data:Object)
Local testThreadData:TTestThreadData = TTestThreadData(data)
Local asdf:String
Try
noop "bla"
Throw "aaaaaaaa"
If True Then noop ""
Catch e:Object
End Try
noop "done"
End Function
Function noop(s:String)
End Function
gdb reports the segfault at this location:
#0 0x0000000076eba59b in ntdll!EtwEventSetInformation ()
from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1 0x000007fefd40e5a3 in msvcrt!longjmp ()
from C:\Windows\system32\msvcrt.dll
No symbol table info available.
#2 0x0000000000420d8d in bbExThrow (p=p@entry=0x43f130 <_s1>)
at C:/Programmierung/BlitzMax-NG latest/mod/brl.mod/blitz.mod/blitz_ex.c:141
st = <optimized out>
[...]
These segfaults only happen when building for x64/Windows/Release. They may not be reproducible with this exact code on other machines. They seem to be influenced by gcc/MinGW optimizations, because they stop happening when building without optimization level -O3, and they also stop happening when very minor changes to the code are made, such as
removing the unused variable asdf
removing the call to noop
changing the parameter of noop to Int and passing 0 instead
removing the unreachable statement If True Then noop ""
After spending quite a while trying to find the problem, I've come to believe it's a bug in the setjmp/longjmp implementation in MinGW that has existed for several years. Info on this can be found here:
I've experienced segfaults caused by using the
Throwstatement. These happen consistently on my machine when executing certain builds, but only under extremely specific conditions. For example, I've been able to consistenly produce crashes on my machine with the following code:gdb reports the segfault at this location:
These segfaults only happen when building for x64/Windows/Release. They may not be reproducible with this exact code on other machines. They seem to be influenced by gcc/MinGW optimizations, because they stop happening when building without optimization level -O3, and they also stop happening when very minor changes to the code are made, such as
asdfnoopnooptoIntand passing0insteadIf True Then noop ""After spending quite a while trying to find the problem, I've come to believe it's a bug in the setjmp/longjmp implementation in MinGW that has existed for several years. Info on this can be found here: