Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unknown system error 0 via Proc::Async #5802

Closed
p6rt opened this issue Nov 15, 2016 · 6 comments
Closed

unknown system error 0 via Proc::Async #5802

p6rt opened this issue Nov 15, 2016 · 6 comments

Comments

@p6rt
Copy link

p6rt commented Nov 15, 2016

Migrated from rt.perl.org#130107 (status was 'resolved')

Searchable as RT130107$

@p6rt
Copy link
Author

p6rt commented Nov 15, 2016

From @gfldex

use v6;

CATCH { default { say .^name; say .Str } }

my $find = Proc​::Async.new(|<find / -print>);

react {
  whenever $find.stdout(​:bin) -> $line {
  QUIT { when X​::AdHoc { say .backtrace.WHAT; say .^name,
  .Str; } }
  print $line.decode('utf8-c8');
  }

  whenever $find.stderr(​:bin) -> $line {
  QUIT { say .^name }
# put "FAIL​: $line"
  }

  $find.start;
}

# OUTPUT (after some time)​:
# X​::AdHoc Unknown system error 0

@p6rt
Copy link
Author

p6rt commented Nov 15, 2016

From @timo

The issue is that libuv will under some circumstances call the read
callback with an nread of 0 (deliberately the number 0), which we
interpret as an error.

The Solution™ is either to not call async_read at all when nread is 0,
or to just return early from async_read when nread is 0.

@p6rt
Copy link
Author

p6rt commented Nov 15, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Nov 16, 2016

From @jnthn

On Tue, 15 Nov 2016 09​:46​:14 -0800, timo wrote​:

The issue is that libuv will under some circumstances call the read
callback with an nread of 0 (deliberately the number 0), which we
interpret as an error.

The Solution™ is either to not call async_read at all when nread is 0,
or to just return early from async_read when nread is 0.

Or, even easier, to just change the incorrect `nread > 0` check to an `nread >= 0` check, which is what I've done in MoarVM commit 20e968b.

Remaining question is if/how we should test this, short of just taking the code in here, adding a platform check for places that have a `find` command, and shoving it in as a stress test. Thoughts welcome.

@p6rt
Copy link
Author

p6rt commented Oct 15, 2017

From @zoffixznet

On Wed, 16 Nov 2016 07​:49​:26 -0800, jnthn@​jnthn.net wrote​:

Remaining question is if/how we should test this

Committed a concoction that reliably exercises the bug ~90% of the time and runs fast enough on HEAD​: Raku/roast@bc8b66866b

@p6rt
Copy link
Author

p6rt commented Oct 15, 2017

@zoffixznet - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Oct 15, 2017
@lizmat lizmat changed the title unkown system error 0 via Proc::Async unknown system error 0 via Proc::Async Jan 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant