# New Ticket Created by Sam S.
# Please include the string: [perl #131870]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=131870 >
When the same regex is used concurrently from multiple `start` threads,
looking up already matched captures like $0 or $<foo> from an embedded
code block *inside* that regex is unreliable:
➜ await do for ^10 -> $i { start { "A".match: /(“A”) { say "BOOM:
$i) ", $0 if not $0 }/ } }
BOOM: 2) Nil
BOOM: 4) Nil
BOOM: 2) ｢A｣
BOOM: 3) ｢A｣
BOOM: 6) Nil
That example shouldn't print anything, because `$0` should always be a
truthy `Match` object after the `(“A”)`.
But in practice, it demonstrates the incorrect behavior shown above on
most runs: *Some* iterations (different ones each time) seem to see `$0`
as `Nil` or as a falsy `Match`.
Additional failure modes that occur more rarely:
- "Type check failed in binding to parameter '<anon>';" error
- hanging indefinitely
Increase the `^10` to `^1000` or so to guarantee failure.
---
Bisect finds:
https://gist.github.com/c04a40f14712ce5a67dc171f87d3bcdb
https://github.com/rakudo/rakudo/commit/08e39ee
However:
<Zoffix> It's not a regression tho
<Zoffix> Or maybe it is.
<Zoffix> It's just before that commit, it looks like the $/ was
shared around, so it wasn't necesarily "not $0"
<Zoffix> c: 08e39ee2653b1ae^ await ^100 .map: -> $i { $/ = 42;
start { "$i".match: /(\d+)/; if $i != +$0 { say "Boom: $i $0" } } }
<committable6> Zoffix,
https://gist.github.com/557c6716c35afeee06cd90a3daf22c47
<Zoffix> Yup.
---
This is Rakudo version 2017.07-136-gda4a0f50a built on MoarVM version
2017.07-318-g604da4d0
implementing Perl 6.c.
