[jruby-user] Intermittent Bad File Descriptor on close

19 views
Skip to first unread message

Matt Hauck

unread,
May 16, 2013, 5:23:28 PM5/16/13
to us...@jruby.codehaus.org
Hello folks. I have recently upgraded from 1.6.5.1 to 1.7.3, and am seeing a strange intermittent Bad File Descriptor error on closing a file. The offending line is a simple "File.read" (from Gem::Specification::load). After searching for a bit and trying to dig into the internals of RubyIO and RubyFile I figured I'd just ask you all for some pointers. 

Context:
- A rails application bundled as a war file with warbler
- A ruby script ("script/main") bundled together in that app which runs some executable-type tasks 
- Deployed onto a windows machine and run with IBM java 
- A two step process of running script/main: (1) Launch a java process that unzips the war file into a temporary directory; (2) Launch another process that runs script/main via a ScriptingContainer. 

It is during this last process, starting up the rails app, it chokes on line 7 of boot.rb, which is this:
require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])
Here's the stacktrace from then on out:
Unknown error: #<Errno::EBADF: Bad file descriptor - Bad file descriptor>
    org/jruby/RubyIO.java:2052:in `close'
    org/jruby/RubyFile.java:236:in `close'
    org/jruby/RubyIO.java:3617:in `read'
    org/jruby/RubyIO.java:3708:in `read'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/specification.rb:541:in `load'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/specification.rb:269:in `_all'
    org/jruby/RubyArray.java:1613:in `each'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/specification.rb:268:in `_all'
    org/jruby/RubyArray.java:1613:in `each'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/specification.rb:267:in `_all'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/specification.rb:410:in `each'
    org/jruby/RubyEnumerable.java:563:in `find'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/specification.rb:442:in `find_by_path'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems.rb:206:in `try_activate'
    jar:file:/C:/Users/qa/AppData/Local/Temp/war613215970041497838extract/WEB-INF/lib/jruby-stdlib-1.7.3.ibm.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:59:in `require'
    config/boot.rb:7:in `(root)'

Basically, it throws a Errno::EBADF when trying to File.read one of the gemspec files unpacked from the war file. I have been trying to reproduce with some debug output in specification.rb to try to figure out which gemspec file it is, and to see if there is one particularly offensive gemspec file, or if just fails randomly without pattern. 

Any ideas on what might be causing this?

-- 
Matt Hauck

Charles Oliver Nutter

unread,
May 17, 2013, 10:53:25 AM5/17/13
to jruby-user
Pretty complicated setup...

Is it possible for you to get a raw Java backtrace for this? The Java property to set would be jruby.backtrace.style=RAW, which should give us all the Java line numbers down to the actual exception.

This may be easy to fix if there's a way for us to reproduce it. Usually I would expect this means there's a double-close happening somewhere, but it's hard to tell.

- Charlie

Matt Hauck

unread,
May 17, 2013, 4:46:27 PM5/17/13
to us...@jruby.codehaus.org
Haha yeah…  I will turn on that flag and upgrade to 1.7.4 and see if can reproduce it or not.

-- 
Matt Hauck

Reply all
Reply to author
Forward
0 new messages