From @masak

<lucasb> m​: Failure.new(Exception.new)
<camelia> rakudo-moar a073f5​: OUTPUT«No exception handler located for
catch [...]
<lucasb> m​: Failure.new(Exception.new); 1
<camelia> rakudo-moar a073f5​: OUTPUT«(signal SEGV)»
<lucasb> I don't know why the last statement is special for rakudo...
<moritz> it's not evaluated in sink context
<lucasb> In "2;3;4", only 2 and 3 get warnings for useless use
<moritz> which is kinda a bug
<moritz> in the general case, when you have code inside a block, the
last statement is returned
<moritz> hence it's not in sink context
<moritz> and we haven't fixed that for the mainline
<jnthn> For the mainline, we didn't fix it 'cus the REPL wants it that
way also...
<moritz> right
* jnthn will investigate the SEGV
<moritz> m​: Failure.new(Exception.new).sink
<camelia> rakudo-moar a073f5​: OUTPUT«(signal SEGV)»
<moritz> there ya go
<lucasb> moritz++
* masak submits rakudobug
<moritz> Exception.new leaves $!ex and $!bt undefined
<moritz> but the rest of the code assumes that they are set
<moritz> and it's the catching/throwing code that generates a new
exception and binds $!ex and $!bt into them
<jnthn> moritz​: Still shouldn't SEGV either way...

From @jnthn

On Fri May 01 06​:16​:20 2015, masak wrote​:

<lucasb> m​: Failure.new(Exception.new)
<camelia> rakudo-moar a073f5​: OUTPUT«No exception handler located for
catch [...]
<lucasb> m​: Failure.new(Exception.new); 1
<camelia> rakudo-moar a073f5​: OUTPUT«(signal SEGV)»
<lucasb> I don't know why the last statement is special for rakudo...
<moritz> it's not evaluated in sink context
<lucasb> In "2;3;4", only 2 and 3 get warnings for useless use
<moritz> which is kinda a bug
<moritz> in the general case, when you have code inside a block, the
last statement is returned
<moritz> hence it's not in sink context
<moritz> and we haven't fixed that for the mainline
<jnthn> For the mainline, we didn't fix it 'cus the REPL wants it that
way also...
<moritz> right
* jnthn will investigate the SEGV
<moritz> m​: Failure.new(Exception.new).sink
<camelia> rakudo-moar a073f5​: OUTPUT«(signal SEGV)»
<moritz> there ya go
<lucasb> moritz++
* masak submits rakudobug
<moritz> Exception.new leaves $!ex and $!bt undefined
<moritz> but the rest of the code assumes that they are set
<moritz> and it's the catching/throwing code that generates a new
exception and binds $!ex and $!bt into them
<jnthn> moritz​: Still shouldn't SEGV either way...

It no longer SEGVs​:

C​:\consulting\rakudo>perl6-m -e "Failure.new(Exception.new); 1"
Unhandled exception​: concatenate requires a concrete string, but got null
  at <unknown>​:1 (././CORE.setting.moarvm​:print_exception​:4294967295)
from src/gen/m-CORE.setting​:29455 (././CORE.setting.moarvm​:<anon>​:40)

But that probably isn't the right behavior either. So, the MoarVM bug that caused the SEGV is gone, but we should figure out the Rakudo behavior we want.

The RT System itself - Status changed from 'new' to 'open'

From @AlexDaniel

Heh, this behavior lives its own life. See https://gist.github.com/Whateverable/df882a7545b2aa4cd0575909934f4c48

Since 2017.07 it is producing this message​:

Died with Exception

Actually thrown at​:
  in block <unit> at /tmp/m_9jvp4WTp line 1

I think that's reasonable. Marking as ｢testneeded｣.

On 2015-05-01 07​:34​:20, jnthn@​jnthn.net wrote​:

On Fri May 01 06​:16​:20 2015, masak wrote​:

<lucasb> m​: Failure.new(Exception.new)
<camelia> rakudo-moar a073f5​: OUTPUT«No exception handler located for
catch [...]
<lucasb> m​: Failure.new(Exception.new); 1
<camelia> rakudo-moar a073f5​: OUTPUT«(signal SEGV)»
<lucasb> I don't know why the last statement is special for rakudo...
<moritz> it's not evaluated in sink context
<lucasb> In "2;3;4", only 2 and 3 get warnings for useless use
<moritz> which is kinda a bug
<moritz> in the general case, when you have code inside a block, the
last statement is returned
<moritz> hence it's not in sink context
<moritz> and we haven't fixed that for the mainline
<jnthn> For the mainline, we didn't fix it 'cus the REPL wants it
that
way also...
<moritz> right
* jnthn will investigate the SEGV
<moritz> m​: Failure.new(Exception.new).sink
<camelia> rakudo-moar a073f5​: OUTPUT«(signal SEGV)»
<moritz> there ya go
<lucasb> moritz++
* masak submits rakudobug
<moritz> Exception.new leaves $!ex and $!bt undefined
<moritz> but the rest of the code assumes that they are set
<moritz> and it's the catching/throwing code that generates a new
exception and binds $!ex and $!bt into them
<jnthn> moritz​: Still shouldn't SEGV either way...

It no longer SEGVs​:

C​:\consulting\rakudo>perl6-m -e "Failure.new(Exception.new); 1"
Unhandled exception​: concatenate requires a concrete string, but got
null
at <unknown>​:1
(././CORE.setting.moarvm​:print_exception​:4294967295)
from src/gen/m-CORE.setting​:29455
(././CORE.setting.moarvm​:<anon>​:40)

But that probably isn't the right behavior either. So, the MoarVM bug
that caused the SEGV is gone, but we should figure out the Rakudo
behavior we want.

From @zoffixznet

Tests​: rakudo/rakudo@1101fea1832c4ef49cc7ad33
  Raku/roast@65336f6eb10be93db7b546a4

@zoffixznet - Status changed from 'open' to 'resolved'