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

IO#read_nonblock throwing EOFError with "exception: false" #4827

Closed
HoneyryderChuck opened this issue Oct 24, 2017 · 5 comments
Closed

IO#read_nonblock throwing EOFError with "exception: false" #4827

HoneyryderChuck opened this issue Oct 24, 2017 · 5 comments
Labels

Comments

@HoneyryderChuck
Copy link

@HoneyryderChuck HoneyryderChuck commented Oct 24, 2017

I'm using exceptionless non-blocking IO API with Jruby 9.1.13.0. In a busy loop I have, it returns (predictably) :wait_readable, until it doesn't, and I get the message:

 EOFError: No message available

I thought that, by using exception: false, that the nonblocking APIs can't throw exception, but rather, :wait_readable/writable when buffer is unavailable, and nil when IO is closed (equivalent to EOFError in older rubies). In fact, this behaviour is consistent in ruby 2.3.0 and newer.

However, I can't seem to find documentation validating this. As of ruby-doc, this is only enforced since 2.4.2, and only for #read_nonblock. But I think this is more a case of the docs not being up-to-date.

@HoneyryderChuck
Copy link
Author

@HoneyryderChuck HoneyryderChuck commented Oct 24, 2017

Also, dunno if related, but although EOFed, it's still selectable:

loop do
  r, w = IO.select([r], [w])
  r.each do |reader|
    begin
      read.read_nonb...
    rescue EOFError
    end
  end
end

which is another difference with CRuby.

@headius
Copy link
Member

@headius headius commented Oct 27, 2017

I believe you are correct in your expectations. I'll have a look.

@headius
Copy link
Member

@headius headius commented Oct 27, 2017

If you are able to reproduce it, pass -Xbacktrace.style=full to JRuby and post the resulting trace. It would help me see where it's going wrong.

@headius
Copy link
Member

@headius headius commented Oct 27, 2017

I believe I have fixed this in fcd7d73 but I'd like to add or find a test that can trigger this behavior. Any additional information you can provide would be helpful!

@headius headius added this to the JRuby 9.1.14.0 milestone Oct 27, 2017
@headius headius added the core label Oct 27, 2017
@headius headius closed this in fcd7d73 Oct 27, 2017
@HoneyryderChuck
Copy link
Author

@HoneyryderChuck HoneyryderChuck commented Oct 31, 2017

I believe that the backtrace you need is this:

 java/lang/Thread.java:1552:in `getStackTrace'
org/jruby/runtime/backtrace/TraceType.java:246:in `getBacktraceData'
org/jruby/runtime/backtrace/TraceType.java:47:in `getBacktrace'
org/jruby/RubyException.java:235:in `prepareBacktrace'
org/jruby/exceptions/RaiseException.java:216:in `preRaise'
org/jruby/exceptions/RaiseException.java:183:in `preRaise'
org/jruby/exceptions/RaiseException.java:111:in `<init>'
org/jruby/Ruby.java:4138:in `newRaiseException'
org/jruby/Ruby.java:4093:in `newEOFError'
org/jruby/RubyIO.java:2907:in `getPartial'
org/jruby/RubyIO.java:2812:in `doReadNonblock'
org/jruby/RubyIO.java:2803:in `read_nonblock'
org/jruby/RubyIO$INVOKER$i$0$2$read_nonblock.gen:-1:in `call'
org/jruby/internal/runtime/methods/JavaMethod.java:729:in `call'
org/jruby/internal/runtime/methods/DynamicMethod.java:216:in `call'
org/jruby/runtime/callsite/CachingCallSite.java:225:in `call'

To reproduce this in a script is a bit non-trivial, as this doesn't happen all the time in my tests (just in a particular one, where more than the usual payload passed between sockets). Maybe I can test this again once 9.1.14.0 is out the door.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.