Skip Menu |
Report information
Id: 131755
Status: resolved
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: cpan [at] zoffix.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Weird 'Reading from filehandle failed: Bad file descriptor' Error Affected by Comments in Code
Download (untitled) / with headers
text/plain 781b
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.
RT-Send-CC: perl6-compiler [...] perl.org
I fudged the flopping test for this ticket in https://github.com/perl6/roast/commit/4748a283e1
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
On Sat, 15 Jul 2017 12:07:19 -0700, cpan@zoffix.com wrote: Show quoted text
> 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
RT-Send-CC: perl6-compiler [...] perl.org
On Mon, 17 Jul 2017 02:19:39 -0700, jnthn@jnthn.net wrote: Show quoted text
> On Sat, 15 Jul 2017 12:07:19 -0700, cpan@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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org