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

Comments

Projects
None yet
2 participants
@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

This comment has been minimized.

Show comment
Hide comment
@HoneyryderChuck

HoneyryderChuck 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.

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

This comment has been minimized.

Show comment
Hide comment
@headius

headius Oct 27, 2017

Member

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

Member

headius commented Oct 27, 2017

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

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Oct 27, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@headius

headius Oct 27, 2017

Member

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!

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

@headius headius closed this in fcd7d73 Oct 27, 2017

@HoneyryderChuck

This comment has been minimized.

Show comment
Hide comment
@HoneyryderChuck

HoneyryderChuck 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.

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