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.

Sign up for GitHub

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

Jump to bottom

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
core
Milestone
JRuby 9.1.14.0

Comments

@HoneyryderChuck
Copy link

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

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 commented Oct 27, 2017

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

@headius
Copy link
Member

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 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
@HoneyryderChuck
Copy link
Author

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
Assignees
No one assigned
Labels
core
Projects
None yet
Milestone
JRuby 9.1.14.0
Development

No branches or pull requests
2 participants
@headius @HoneyryderChuck