[perl #131858] [REGRESSION] default $.nl-in on IO::Handle does not correctly work in subclasses
On Tue, 08 Aug 2017 04:19:24 -0700, elizabeth wrote:
> reverted c63c57e9a823303e74c06 for now
>
> > On 8 Aug 2017, at 12:21, Zoffix Znet (via RT) > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Zoffix Znet
> > # Please include the string: [perl #131858]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131858 >
> >
> >
> > Currently, this causes breakage in IO::String
> >
> > zoffix@VirtualBox~$ perl6 -e 'class Z is IO::Handle { method x { dd
> > $.nl-in } }.new.x;'
> > $["\n"]
> >
> > zoffix@VirtualBox~$ perl6 -v
> > This is Rakudo version 2017.07-138-ga91ad2d built on MoarVM version
> > 2017.07-318-g604da4d
> >
> > Above, it should give the two-element array, with "\r\n" as another
> > element.
> >
> > AlexDaniel bisected my original code[^1] to point to
> > https://gist.github.com/Whateverable/b26f4103f5da0809e11749b50fdbabb4
> > ¦c63c57e9a823^: «"hello,"» ¦c63c57e: «"hello,\r\nworld!\r\n"»
> >
> > I tried to golf it further, by taking all the relevant bits from
> > IO::Handle into a custom class, but failed to reproduce the issue
> > then.
> >
> > [1]
> > https://gist.github.com/zoffixznet/0c2cbd7acaaf0d3b27d245ad2e2bc737
It seems as if everything is still good after the revert
((2017-08-08)
https://github.com/rakudo/rakudo/commit/67455170ca50bb908f309b77e5ca579eaa21605c
),
tests needed,
[perl #131871] [CONC] [REGEX] Regex code block closing over lexical variable, is not threadsafe
OK, first of all, a bot-friendly (whateverable-friendly specifically) version
of the first snippet is here:
say run(:out, , ‘await ^100 .map: -> $i { start { "".match(/ { print
$i } /) } }’).out.slurp-rest eq (^100).join
And that points to the better-sched merge as noted by dogbert++
The second snippet is faulty in a completely different way, but it is also
fixed.
So the second snippet is living its own life which is probably more interesting
than mine:
On 2015.12 and onwards it was giving False. Then it was fixed (?) in:
(2017-12-19)
https://github.com/rakudo/rakudo/commit/c51f1796e627e93b34e1b06b46c6dccb82549e04
and therefore started to give True. However, after this commit it got broken
(?) again:
(2018-02-07)
https://github.com/rakudo/rakudo/commit/c0c7756f4b5c1d5c79eea56a30a6e43b17b7d408
and therefore started to give False. But it didn't take long to fix that again
in:
(2018-03-04)
https://github.com/rakudo/rakudo/commit/fb882d498edec985a1bd645208862681a64c8743
and so now it gives True again.
Please write tests for this so that it does not get worse than that :)
***⚠ if you write tests, please test both snippets ⚠***
On 2017-08-09 13:06:46, sml...@gmail.com wrote:
> This bug was found as a side-effect of RT #131870, but might be a
> separate issue:
>
> ➜ await ^10 .map: -> $i { start { "".match(/ { say $i } /) } }
> 7
> 7
> 6
> 6
> 7
> 8
> 9
> 9
> 9
> 9
>
> Somehow, multiple iterations see the same value for the closed-over
> variable `$i`.
>
> Without the `await` and `start`, it prints each number from 0 to 9
> exactly once, like it should.
>
> ---
>
> Note that the problem is only with *code blocks* inside regexes. When a
> lexical variable is interpolated into the top-level of a regex directly,
> things seem to work fine:
>
> ➜ say await ^10 .map: -> $i { start { "0123456789".match(/ $i /) } }
> (｢0｣ ｢1｣ ｢2｣ ｢3｣ ｢4｣ ｢5｣ ｢6｣ ｢7｣ ｢8｣ ｢9
>
> ---
>
> Bot-friendly version that reliably prints `False`, even though it should
> print `True`:
>
> my $c = Channel.new; (await ^100 .map: -> $i { start "".match(/ {
> $c.send: $i } /) }); $c.close; say $c.sort.list eqv (^100).list;
>
> According to bisectable6 and committable6 this prints `False` for all
> past Perl 6 releases, so it's not a regression but rather an old bug.
[perl #131871] [CONC] [REGEX] Regex code block closing over lexical variable, is not threadsafe
On Wed, 09 Aug 2017 13:06:46 -0700, sml...@gmail.com wrote:
> This bug was found as a side-effect of RT #131870, but might be a
> separate issue:
>
> ➜ await ^10 .map: -> $i { start { "".match(/ { say $i } /) } }
> 7
> 7
> 6
> 6
> 7
> 8
> 9
> 9
> 9
> 9
>
Fixed with one or more of (better-sched)
7c18112c59d20413b82356e5c48b38d8a66fc7ea
c285b489c6629ccdf0c4cb11d2d695b9ef1f890c
7fcab1067de4757bfdf2fdd1c66893ce4ab06e1b
89b9ac7830bdc195cb303f5241641e0dbe0ebbde
683037be698d0bdc21b3c23588085b2d076d7a0a
b5605c2dd6d361b705a59136c8ad641f245a5da5
c50d35a90e66346157b31cd92643c2a64e801c24
de311f46a98f13a5b0211d2585fbd9b17ce1bf2c
340d8ed3bb4b45af85708771bea396cf862a7330
3b98fb9e396d040a8cb2c32d23cee54a5e88f878
596611c8fdc3baf119bc94a8ea30efc0a12cf673
80b49320cf854ac68a17cdd216575ee26e380325
61a77e60a7d936415503d8916fcc7546569e9135
> Somehow, multiple iterations see the same value for the closed-over
> variable `$i`.
>
> Without the `await` and `start`, it prints each number from 0 to 9
> exactly once, like it should.
>
> ---
>
> Note that the problem is only with *code blocks* inside regexes. When a
> lexical variable is interpolated into the top-level of a regex directly,
> things seem to work fine:
>
> ➜ say await ^10 .map: -> $i { start { "0123456789".match(/ $i /) } }
> (｢0｣ ｢1｣ ｢2｣ ｢3｣ ｢4｣ ｢5｣ ｢6｣ ｢7｣ ｢8｣ ｢9
>
> ---
>
> Bot-friendly version that reliably prints `False`, even though it should
> print `True`:
>
> my $c = Channel.new; (await ^100 .map: -> $i { start "".match(/ {
> $c.send: $i } /) }); $c.close; say $c.sort.list eqv (^100).list;
>
> According to bisectable6 and committable6 this prints `False` for all
> past Perl 6 releases, so it's not a regression but rather an old bug.
[perl #131870] [CONC] [REGEX] Capture lookup inside regex is not threadsafe
On Wed, 09 Aug 2017 13:32:58 -0700, sml...@gmail.com wrote:
> Heh, on further thought, they may be the same issue after all.
>
> In `/(...) { ... $i ... $0 ... }`, both the $i and the $0 (or $/
> rather) are outer lexicals from the point of view of the curly block,
> right?
>
> So it might be a general problem with the way that *code blocks inside
> regexes* access outer lexicals.
>
> (It doesn't happen with code blocks *outside* of regexes, and as the
> other ticket demonstrates, also doesn't happen inside the regex-
> portion of regexes.)
It was initially broken with commit (2016-08-03)
https://github.com/rakudo/rakudo/commit/08e39ee2653b1ae5144d4158a4f8ad03193e7024
and fixed with the better-sched merge, i.e.
7c18112c59d20413b82356e5c48b38d8a66fc7ea
c285b489c6629ccdf0c4cb11d2d695b9ef1f890c
7fcab1067de4757bfdf2fdd1c66893ce4ab06e1b
89b9ac7830bdc195cb303f5241641e0dbe0ebbde
683037be698d0bdc21b3c23588085b2d076d7a0a
b5605c2dd6d361b705a59136c8ad641f245a5da5
c50d35a90e66346157b31cd92643c2a64e801c24
de311f46a98f13a5b0211d2585fbd9b17ce1bf2c
340d8ed3bb4b45af85708771bea396cf862a7330
3b98fb9e396d040a8cb2c32d23cee54a5e88f878
596611c8fdc3baf119bc94a8ea30efc0a12cf673
80b49320cf854ac68a17cdd216575ee26e380325
61a77e60a7d936415503d8916fcc7546569e9135
[perl #131914] [REGRESSION] Rakudo/Moar taking more memory at launch.
Interestingly, I can't reproduce it as well… But the numbers are still higher than they were, so I guess the ticket is valid? Here's the output on all releases: https://gist.github.com/Whateverable/8687cceb1bfcf39e9818cef819d29391 I'd say we can close it once we go back to 50-ish. On 2017-08-17 02:23:26, jn...@jnthn.net wrote: > On Wed, 16 Aug 2017 14:53:05 -0700, alex.jakime...@gmail.com wrote: > > Also, it's not any different on HEAD: > > > > committable6test: 9658dd98c9dd8ec^^,9658dd98c9dd8ec,HEAD > > say > > "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024 > > AlexDaniel, ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: > > «138220» > > ¦HEAD(3e70d44): «136436» > > > > On 2017-08-16 14:27:37, alex.jakime...@gmail.com wrote: > > > Note that the tests on 92bd7e4^ and 92bd7e4 are not very related to > > > this > > > particular issue. > > > > > > To put simply: it went from 58628 to 138220 because of changes > > > related > > > to this > > > commit (or maybe one or two commits before it): > > > > > https://github.com/rakudo/rakudo/commit/9658dd98c9dd8ecbefc606a08357e59718e328c2 > > > > > > For Proc → Proc::Async issue see this ticket: > > > https://rt.perl.org/m/ticket/show?id=131915 > > > > > > Bisect logs: > > > https://gist.github.com/6a7a6bfbc157bac3d06e9d2d58306846 > > > https://gist.github.com/5cf477671560bad21251207895708d94 > > > > > > > > > On 2017-08-16 14:21:25, scoli...@gmail.com wrote: > > > > After some test against various release of rakudo it appear that > > > > there > > > > is a huge step in the memory taken by rakudo/moar at launch. > > > > (after > > > > 2017.05) > > > > It's like up to 55Mb to 120Mb+ > > > > > > > > It was tested by reading the memory info in /proc/pid/statm (the > > > > number is in Kbytes) > > > > > > > > committable6test: > > > > 92bd7e4f54a9^,92bd7e4f54a9,9658dd98c9dd8ec^^,9658dd98c9dd8ec say > > > > "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * 4096 / 1024 > > > > AlexDaniel, ¦92bd7e4f54a9^: «55752» ¦92bd7e4: > > > > «55896» ¦9658dd98c9dd8ec^^: «58628» ¦9658dd9: «138220» > > I can't reproduce such an sizable increase at HEAD or > MoarVM/NQP/Rakduo: > > $ ./perl6-m -e 'say "/proc/$*PID/statm".IO.lines[0].split(/\s/)[5] * > 4096 / 1024' > 79904
[perl #131879] [REGRESSION] Memory “leak”
dogbert++ noticed me that this ticket exist. I totally forgot. OK, that particular leak is gone I think, but there were other (newer) issues. See https://github.com/rakudo/rakudo/issues/1280 Closing this ticket in favor of GH issue. On 2017-08-14 14:37:54, alex.jakime...@gmail.com wrote: > OK, this is still not resolved, but it got noticeably better. > > The issue is reproducible with the snippet provided in the original > report. > On 2017-08-11 10:01:42, alex.jakime...@gmail.com wrote: > > There was some progress on this. jnthn++ > > > > I guess the most promising commit regarding this issue is > > > https://github.com/MoarVM/MoarVM/commit/0d2e5f8cc0264eb495ea4f20f3a0c90d05d55710 > > , but there's at least one other commit that could've improved the > > situation ( > > > https://github.com/rakudo/rakudo/commit/c59b986785fe17f53e1664af1aa60e785ff31624 > > ). > > > > I will test this again after we have MoarVM bumped (or sooner if I > > have time). > > > > On 2017-08-10 10:43:42, alex.jakime...@gmail.com wrote: > > > After recent rakudo updates whateverables started having some > > > problems. At first I thought that they simply became slower, but > > > upon > > > further investigation it turned out that their memory usage was > > > increasing during the operation (which is most likely the reason > > > for > > > them to slow down during the execution). > > > > > > MasterDuke++ did a lot of investigation and measurements, so I'm > > > hoping to see his comments here. I don't have much to say, so I'll > > > just give a bunch of links. Please bear with me. > > > > > > Initial conversation and relatively golfed down code: > > > https://irclog.perlgeek.de/moarvm/2017-08-05#i_14973432 > > > https://gist.github.com/MasterDuke17/685b627a6a2749483dc5ec09c6a777a4 > > > > > > dogbert11++ reproducing the issue > > > https://irclog.perlgeek.de/moarvm/2017-08-06#i_14976177 > > > > > > (note that it seems like there's no memory leak, but the memory > > > usage > > > is growing) > > > > > > More: https://irclog.perlgeek.de/perl6/2017-08-08#i_14987204 > > > > > > > > > I don't know if this affects anybody else, but jdv79++ was talking > > > about some memory issues recently: > > > https://irclog.perlgeek.de/perl6- > > > dev/2017-08-05#i_14973488
