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

Passing an Exception object to Failure.new segfaults (SEGV) in sink context in Rakudo #3799

Closed
p6rt opened this issue May 1, 2015 · 6 comments
Closed

Comments

@p6rt
Copy link

@p6rt p6rt commented May 1, 2015

Migrated from rt.perl.org#124434 (status was 'resolved')

Searchable as RT124434$

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2015

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...

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2015

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.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2015

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

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Dec 1, 2017

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.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Dec 11, 2017

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Dec 11, 2017

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant