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

pipes/handles are closed when the jruby main thread exits, which can lead to unexpected behavior #2368

headius opened this issue Dec 29, 2014 · 2 comments


Copy link

@headius headius commented Dec 29, 2014


Original report

Basically, it appears that if you open a pipe, then the main thread exits, other threads still running "stop begin able to write to that pipe" (my assumption is it was closed when the main thread exited). I think I've run into this before, but couldn't find a ticket for it easily, so sorry if it's a dupe. It seems to reproduce at least in windows 7 with jdk 1.6 and windows xp with jdk 7.

This snippet should output 'hello'
 a = IO.popen("jruby -e 'puts gets'", "w")
 sleep 1 # let it start
 timer =, nil)
 timer.repeats=false # may not be necessary
 timer.add_action_listener {
   a.puts 'hello'

 # allow main thread to exit -- uncomment the sleep line and it works as expected.
 # sleep

as is, it responds with

Exception in thread "AWT-EventQueue-0" org.jruby.exceptions.RaiseException: (Errno::EBADF) Bad file descriptor
        at org.jruby.RubyIO.write(org/jruby/
        at org.jruby.RubyIO.write(org/jruby/
        at org.jruby.RubyIO.puts(org/jruby/
        at org.jruby.RubyIO.puts(org/jruby/
        at bad.(root)(bad.rb:10)
        at org.jruby.gen.InterfaceImpl1035124051.actionPerformed(org/jruby/gen/InterfaceImpl1035124051.gen:13)

or within a larger program:

Errno::EBADF: Bad file descriptor - Bad file descriptor                                                    
                            read at org/jruby/                                             
                               ` at file:/C:/installs/jruby-1.7.0/lib/jruby.jar!/jruby/kernel/jruby/process_manager.rb:35                                                                  
                               ` at file:/C:/installs/jruby-1.7.0/lib/jruby.jar!/jruby/kernel/jruby/process_manager.rb:49                                                                  
  set_all_ffmpegs_as_lowest_prio at C:/dev/dirt-simple-usb-surveillance/./lib/go.rb:17                                                                                                     
                    do_something at C:/dev/dirt-simple-usb-surveillance/./lib/go                           
IOError: Stream closed     

The difficult thing with this is that the errors sometimes can manifest themselves "unreliably" because it depends if the main thread has exited yet or not. In my case, sometimes it has, sometimes it hasn't, which makes this a frustrating bug to trace.

Copy link
Member Author

@headius headius commented Dec 29, 2014

Suggested workaround: prevent the main thread from exiting. But your concerns are valid.

@enebo enebo removed this from the JRuby 1.7.19 milestone Jan 28, 2015
@enebo enebo added this to the JRuby 1.7.20 milestone Jan 28, 2015
@enebo enebo added this to the JRuby 1.7.20 milestone Jan 28, 2015
@enebo enebo removed this from the JRuby 1.7.19 milestone Jan 28, 2015
@headius headius removed this from the JRuby 1.7.20 milestone May 4, 2015
Copy link
Member Author

@headius headius commented May 4, 2015

This is unlikely to be fixed now or ever; we'd need to know that one of the many JVM threads is a user thread still active in the system and still dependent on the streams we shut down on exit. The lifecycle of the JRuby instance is only as long as the lifecycle of "main" when running from the command line. If you want to keep it valid longer than that, wait for those threads to shut down in your main thread or block the main thread until it's safe to exit. Treat script exit like app exit.

@headius headius closed this as completed May 4, 2015
@headius headius added this to the Won't Fix milestone May 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants