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

Segfault while indexing with infinite Seq #2120

Closed
taboege opened this issue Jul 23, 2018 · 3 comments
Closed

Segfault while indexing with infinite Seq #2120

taboege opened this issue Jul 23, 2018 · 3 comments
Assignees
Labels
BLOCKER Preventing the next release of rakudo, or just needing attention before the release QAST issues that require working with QAST to fix regression Issue did not exist previously

Comments

@taboege
Copy link
Contributor

taboege commented Jul 23, 2018

The Problem

The following code segfaults using rakudo-moar HEAD via camelia [^1]:

(^10)[2.polymod($_ xx *).map($_ ** *) »%» *] with 1

Interestingly, removing the map (which should produce constant 1) or inlining the with 1 leads to a timeout [^2,3].

On my personal machine with Rakudo-moar 2018.06, it just hangs in all three cases.

Expected Behavior

It should hang as the polymod(1 xx *) produces an infinite list.

Actual Behavior

SIGSEGV, but only when the seemingly useless map and with 1 are left intact.

Environment

  • Works as expected with Rakudo version 2018.06 built on MoarVM version 2018.06,
  • Segfaults with rakudo-moar c47e3681c.

References

[^1] http://colabti.org/irclogger/irclogger_log/perl6?date=2018-07-23#l486
[^2] http://colabti.org/irclogger/irclogger_log/perl6?date=2018-07-23#l504
[^3] http://colabti.org/irclogger/irclogger_log/perl6?date=2018-07-23#l506

@AlexDaniel
Copy link
Contributor

Bisected: (2018-07-09) c2446b0

NQP changes in the bump: Raku/nqp@2018.06-27-gcec76ff79...2018.06-36-g39f1057
Moar changes in the bump: MoarVM/MoarVM@2018.06-103-gaf455397f...2018.06-141-gcae4731

@AlexDaniel AlexDaniel added regression Issue did not exist previously BLOCKER Preventing the next release of rakudo, or just needing attention before the release labels Jul 23, 2018
@zoffixznet
Copy link
Contributor

zoffixznet commented Jul 23, 2018

FWIW, the QAST has two misscoped blocks, so it's pure luck this worked in the past (if it even did)

@zoffixznet zoffixznet added the QAST issues that require working with QAST to fix label Jul 23, 2018
@zoffixznet
Copy link
Contributor

Golf of the scoping issue: {1}() + * with 1

@zoffixznet zoffixznet self-assigned this Jul 23, 2018
zoffixznet added a commit that referenced this issue Jul 23, 2018
Fixes R#2120 #2120

The migrator in whatever currier is too naive and in the branch
that handles block args assumed QAST::WVal of code would just be
the kid. However, it can also be a kid of the kid, placed in some
other ops, like nqp::call.

Fix by doing more thorough search for blocks to migrate by descending
into the kid. Also, wide the nodes we search to all QAST::Nodes. The
original list of nodes just assumed some nodes can't be @(), but
I think all of them can, actually.
ugexe pushed a commit to Raku/roast that referenced this issue Dec 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BLOCKER Preventing the next release of rakudo, or just needing attention before the release QAST issues that require working with QAST to fix regression Issue did not exist previously
Projects
None yet
Development

No branches or pull requests

3 participants