RubyZip Zip::ZipFile#read raises TypeError under JRuby; does not do so under MRI
--------------------------------------------------------------------------------

                 Key: JRUBY-1617
                 URL: http://jira.codehaus.org/browse/JRUBY-1617
             Project: JRuby
          Issue Type: Bug
          Components: Core Classes/Modules
    Affects Versions: JRuby 1.1b1, JRuby 1.x
         Environment: rubyzip 0.9.1 on: 
- JRuby trunk on OS X 10.4.11 and JRuby 1.1b1 on Windows XP SP2
- MRI 1.8.6 on OS X 10.4.11
            Reporter: David Yip
            Priority: Minor
         Attachments: zip-io-src.patch, zip-io-test.patch

Zip::ZipFile#read from rubyzip v0.9.1 raises a TypeError under JRuby, but does 
not do so under MRI v1.8.6.   The following Ruby program demonstrates the issue:

http://pastie.caboo.se/121140

Under MRI, the result of executing the program are as follows:

$ ruby test.rb 
# Filters added to this controller apply to all controllers in the application.
# Likewise, all the methods added will be available for all controllers.

class ApplicationController < ActionController::Base
  helper :all # include all helpers, all the time

  # See ActionController::RequestForgeryProtection for details
  # Uncomment the :secret if you're not using the cookie session store
  protect_from_forgery # :secret => '4e5a2bdb639095e76c9f9958d7d8b84f'
end

===

Under JRuby, the result of executing the program are as follows:

$ bin/jruby test.rb 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zip.rb:186:in
 `sysread': can't convert NilClass into nil (TypeError)
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zip.rb:128:in
 `sysread'
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/ioextras.rb:49:in
 `read'
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zip.rb:1435:in
 `get_input_stream'
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zip.rb:1411:in
 `get_input_stream'
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zip.rb:1435:in
 `read'
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zip.rb:1435:in
 `read'
        from 
/Users/trythil/src/jruby/trunk/jruby/lib/ruby/gems/1.8/gems/rubyzip-0.9.1/lib/zip/zipfilesystem.rb:383:in
 `read'
        from test.rb:3:in `read'
        from test.rb:1:in `open'
        from test.rb:3:in `open'


===


I have attached two patches that addresses this issue.  There appear to be two 
causes of this problem, and the patches address both problems.

(1) IO.read(length, buffer), in MRI, functions normally even if buffer is nil; 
i.e. it reads up to {length} bytes, or EOF if length = nil, and returns those 
bytes.  In JRuby, passing nil for the buffer argument would result in a 
TypeError.  This patch modifies RubyIO.java to handle this case, and adds a 
corresponding test case to test_io.rb.

(2) The fallback logic in org.jruby.util.ZlibInflate.inflate 
(ZlibInflate.java:100-106) re-instantiates the Inflater object, which 
incorrectly resets the Inflater's internal state.  In particular, the result of 
Inflater.finished() will be incorrect if all input has been read from a stream 
and inflated: finished() will evaluate to false when it should evaluate to true.

==

Any feedback on these changes would be greatly appreciated.  In particular, I'm 
not entirely sure what the rationale for re-instantiating the Inflater class 
was, and I'm not sure if removing that re-instantiation will have any negative 
side effects in other Zlib-related processes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply via email to