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

Reply via email to