Bad file descriptor with Nokogiri 1.5.0

[tychobrailleur]

I am getting a Bad file descriptor error when using Nokogiri 1.5.0 with JRuby 1.6.2 and 1.6.3 on Win7. I have managed to reproduce the issue with a very simple script which works with MRI:

require 'rubygems'
require 'optparse'
require 'nokogiri'

Dir.chdir(ARGV[0])
poms = File.join("**", "pom.xml")
Dir.glob(poms).each do
  |p|
  puts p
  f = File.open(p)
  puts 'parsing...' if $DEBUG
  doc = Nokogiri::XML(f)
  f.close
  puts 'Done.'
end

The XML file being parsed doesn't seem to matter.
Here is the stacktrace:

C:\scripts>jruby -J-Djruby.backtrace.style=raw reduced_script.rb C:\test
core/pom.xml
Errno::EBADF: Bad file descriptor - Bad file descriptor
       getStackTrace at java/lang/Thread.java:1479
    getBacktraceData at org/jruby/runtime/backtrace/TraceType.java:60
        getBacktrace at org/jruby/runtime/backtrace/TraceType.java:26
    prepareBacktrace at org/jruby/RubyException.java:160
            preRaise at org/jruby/exceptions/RaiseException.java:205
            preRaise at org/jruby/exceptions/RaiseException.java:195
              <init> at org/jruby/exceptions/RaiseException.java:112
   newRaiseException at org/jruby/Ruby.java:3302
  newErrnoEBADFError at org/jruby/Ruby.java:2953
            finalize at org/jruby/util/io/OpenFile.java:345
             cleanup at org/jruby/util/io/OpenFile.java:296
              close2 at org/jruby/RubyIO.java:1993
               close at org/jruby/RubyIO.java:1971
               close at org/jruby/RubyFile.java:314
                call at org/jruby/RubyFile$i$0$0$close.gen:65535
        cacheAndCall at org/jruby/runtime/callsite/CachingCallSite.java:292
                call at org/jruby/runtime/callsite/CachingCallSite.java:135
            __file__ at reduced_script.rb:13
                call at reduced_script$block_0$RUBY$__file__:65535
               yield at org/jruby/runtime/CompiledBlock.java:112
               yield at org/jruby/runtime/CompiledBlock.java:95
               yield at org/jruby/runtime/Block.java:130
          eachCommon at org/jruby/RubyArray.java:1596
                each at org/jruby/RubyArray.java:1603
                call at org/jruby/RubyArray$i$0$0$each.gen:65535
        cacheAndCall at org/jruby/runtime/callsite/CachingCallSite.java:302
           callBlock at org/jruby/runtime/callsite/CachingCallSite.java:144
            callIter at org/jruby/runtime/callsite/CachingCallSite.java:153
              (root) at reduced_script.rb:7
           runScript at org/jruby/Ruby.java:671
         runNormally at org/jruby/Ruby.java:575
         runFromMain at org/jruby/Ruby.java:424
       doRunFromMain at org/jruby/Main.java:278
         internalRun at org/jruby/Main.java:198
                 run at org/jruby/Main.java:164
                 run at org/jruby/Main.java:148
                main at org/jruby/Main.java:128

C:\scripts>java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

C:\scripts>jruby -v
jruby 1.6.3 (ruby-1.8.7-p330) (2011-07-07 965162f) (Java HotSpot(TM) 64-Bit Serv
er VM 1.6.0_23) [Windows 7-amd64-java]

C:\scripts>jruby -S gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.5.0 java)

Apologies if this has been already raised.

[tychobrailleur]

This showstopper also occurs on Ubuntu. This means that even the simple example from the Nokogiri tutorial fails with the Bad descriptor error:

require 'rubygems'
require 'nokogiri'

f = File.open("blossom.xml")
doc = Nokogiri::XML(f)
f.close

[agmcleod]

Getting the same issue. My codebase works fine with MRI nokogiri on my OS X machine. Using jruby one on windows.

[flavorjones]

@yokolet - this seems like it should be easy to solve. Would you mind taking a look if you have a moment?

[yokolet]

Sorry, I wasn't aware of this issue. I'll have a look.

[tychobrailleur]

At the time of raising that issue, I had tracked it down to using a relative path in File.open. Using an absolute path was not causing the problem.

[yokolet]

Thanks for additional info.

I fixed this issue in rev. ef406cc .If you have a chance, try master.

Thanks for reporting the bug. And sorry for my really late response.

[tychobrailleur]

Hi Yoko,

I have been able to run my original script using master, so I reckon your fix did the trick indeed. Thanks for that. And still looking forward to your talk! ;-)

[yokolet]

Good to know.

And, yes, I look forward to JRubyConf :)

[avinmathew]

I'm getting this same error on Nokogiri 1.5.5 using JRuby 1.7.0 under Ubuntu 12.04. The error seems to occur when closing a file that has been parsed by Nokogiri. I can use the Nokogiri document if I don't close the file.

Code:

f = File.open("test.xml")
Nokogiri.XML(f)
f.close # Error is caused by this line

test.xml:

<test/>

Versions:

> java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b06)
Java HotSpot(TM) Server VM (build 23.1-b03, mixed mode)

> jruby -v
jruby 1.7.0 (1.9.3p203) 2012-10-22 ff1ebbe on Java HotSpot(TM) Server VM 1.7.0_05-b06 [linux-i386]

> jruby -S gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.5.5 java)

[BrandonMathis]

I'm able to reproduce this bug with nokogiri 1.5.5 in jruby on OSX

irb(main):001:0> f = File.open("spec/fixtures/simple_asset.xml")
=> #<File:spec/fixtures/simple_asset.xml>
irb(main):003:0> require 'nokogiri'
=> true
irb(main):004:0> Nokogiri.XML(f)
=> #nokogiri object (removed)
irb(main):005:0> f.close
Errno::EBADF: Bad file descriptor - Bad file descriptor
    from org/jruby/RubyIO.java:2054:in `close'
    from org/jruby/RubyFile.java:218:in `close'
    from (irb):5:in `evaluate'
    from org/jruby/RubyKernel.java:1065:in `eval'
    from org/jruby/RubyKernel.java:1390:in `loop'
    from org/jruby/RubyKernel.java:1173:in `catch'
    from org/jruby/RubyKernel.java:1173:in `catch'
    from /Users/bemathis/.rbenv/versions/jruby-1.7.0/bin/irb:13:in `(root)'
irb(main):006:0> exit

[jvshahid]

Thanks for reporting this bug. I just confirmed that the issue is on master with JRuby 1.6.7 and JRuby 1.7.0. I'll take a look and get back to you shortly.