On Mon, 17 Jul 2017 02:19:39 -0700, jn...@jnthn.net wrote:
> On Sat, 15 Jul 2017 12:07:19 -0700, c...@zoffix.com wrote:
> > The original failure was in t/spec/S32-io/open.t test that I golfed
> > down to the following:
> >
> > -----------------------8<---------------------------------
> > $*IN = IO::Handle.new: :path('-'.IO);
> > $*IN.open;
> > $*OUT.open: :w;
> >
> > my $w = '-'.IO.open: :w;
> > my $r = '-'.IO.open;
> > $*IN.slurp(:close); #
> > $w.put: 'meow w';
> > $*OUT.put: 'x';
> > -----------------------8<---------------------------------
> >
> > Save that code to file named open.t and then run it like this:
> >
> > $ echo "x" | ./perl6 --ll-exception open.t
> >
> > And it'll die with 'Reading from filehandle failed: Bad file
> > descriptor'
> >
> > This is on Rakudo version 2017.06-252-g83502cc built on MoarVM
> > version
> > 2017.06-91-g146c8fc.
> >
> > Most notably, removing `--ll-exception` parameter or even removing
> > the
> > `#` comment on line 6 causes the bug to disappear.
>
> I investigated this a bit, wondering if the flakiness was a MoarVM
> bug. It turns out that no, MoarVM is doing precisely what is asked of
> it by Rakudo. :-)
>
> The code in question makes the original handle bound in $*IN
> unreachable. At some point GC runs and collects it. Except it doesn't
> right away, because IO::Handle has a DESTROY method. That DESTROY
> method runs and closes the underlying VM handle. However, because the
> standard handles don't open a new handle, but rather obtain the VM-
> level handles for stdin/stderr/stdout, we can end up with two
> IO::Handle instances pointing to the same underlying handle. The
> DESTROY closes it, busting the other handle that holds it.
>
> The various tweaks that hide the issue are simply moving when GC takes
> place, meaning it's too early or too late to collect the object and
> run DESTROY at the time that causes the breakage.
>
> /jnthn
Thanks.
Fix: https://github.com/rakudo/rakudo/commit/0e578c4fea72e36
Test: https://github.com/perl6/roast/commit/f739f03ff439e75a7
