What steps will reproduce the problem? 1. Run the attached setup_production_environment script in a dir with the attached Gemfile

This requires rvm be installed, and ree-1.8.7-2010.02 installed via rvm. It installs bundler to the global gemset, then the gems from the gemfile in a gemset called personal_site.

This should run fine the first time through. 2. Run it a second time, you should get the error: ~/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:49:in `initialize': not in gzip format (Zlib::GzipFile::Error)

What is the expected output? What do you see instead? Expect it to work, see additional info below for the weirdness that looks very much like a ree bug.

What version of the product are you using? On what operating system?

ree 2010.02 OSX 10.6.3

Please provide any additional information below.

I tried to debug the problem by adding a puts between lines 148/149 in:

~/.rvm/gems/ree-1.8.7-2010.02@global/gems/bundler-0.9.26/lib/bundler/source.rb

i.e. the each block in GemCache#specs.

When I ran the script again, it all worked as expected. I removed the puts and put

if false # nop end

and it worked also.

Seems to me this is something very odd in ree if a non related ruby change can "fix" it.

Let me know via email or @chrismcg on twitter if you need more info or can't reproduce with the files I've attached.

I too am seeing this same issue, on the next oldest version of bundler:

Ubuntu Lucid x86_64 Ruby REE 2010.02 (from deb) Bundler 0.9.25 Rails 2.3.5

We are not seeing this issue under Vanilla Ruby 1.8.7 from the Ubuntu Official Repos, only REE.

Everything I have tried that suppresses the issue is complete Voodoo and random.

I have attached our Gemfile, and also the stack trace I get when running "rake -vT --trace".

Jonathan

I'm getting this one too. Very random behavior. We're using the Rackspace cloud. We built three identical servers (using a build script) and 2 worked, and the third failed with this issue.

If we change the order of Gems in our Gemfile (so basically a no-op) then it starts to work again. But the smallest change seems to make it resurface.

As it is, we're moving back to vanilla ruby, this is causing us to many headaches.

-- Ubuntu Lucid x86_64 Ruby REE 2010.02 Bundler 0.9.25 Rails 2.3.5

I'm having this problem too but I thought I'd drop in a note that bundler 1.0.0 beta 4 is working fine for me. Obviously it's not a solution for everyone with it being a beta gem but still, hope it helps.

Same problem here. Using Ubuntu-10.04(64bit, desktop) with REE-2010.02 (compiled via rvm). When running bundle install (bundler-1.0.rc6) it complains:

"~/.rvm/rubies/ree-1.8.7-2010.02/lib/ruby/site_ruby/1.8/rubygems/package/tar_input.rb:49:in `initialize': not in gzip format (Zlib::GzipFile::Error)" See the gist http://gist.github.com/549043

Comment deleted

Problem persists with stable bundler 1.0 ... Deleting bundler meta-data (e.g. cache, tmp, whole-.bundler directory) does not help. Switching back to MRI as I need my bundle installed...

I just ran into this problem with bundler 1.0 final and ree 1.8.7-2010.02; clearing the ~/.rvm/gems/RUBYVERSION/cache directory fixed it for me.

I'm using Bundler extensively on OS X with REE. I've never run into this problem and I can't reproduce it with any Bundler version. REE doesn't modify zlib.

Has anybody ever run into similar problems with non-REE?

>

Comment 8 by honglilai, Today (3 hours ago) I'm using Bundler extensively on OS X with REE. I've never run into this problem and I can't reproduce it with any Bundler version. REE doesn't modify zlib.

Has anybody ever run into similar problems with non-REE?

We switched back to hand-compiling vanilla Ruby 1.8.7 p299 on Ubuntu and have never seen the problem again.

The problem definitely only exists for us when using REE. Or should I say R!EE?

jonathan.hoskin, I understand you might be frustrated by the problem, however it is a fact that REE does not include any changes to zlib and to be able to solve the problem constructive feedback is far more useful.

At this time I suspect that the gem metadata files have somehow became corrupted. Whether that is the fault of REE remains to be seen; for now some more information from people who can reproduce the problem is required.

To those who can reproduce the problem, could you verify that all the .gem files that are cached by Bundler are valid? .gem files are actually just tar files; if you unpack them with tar that should give you two .gz files, data.tar.gz and metadata.gz. Can you try to decompress both files and check that neither give errors?

Do things work again after deleting the cached .gem files?

Hi Guys,

I fixed it by removing my ~/.bundle/ruby/1.8/cache directory. It seems to be a problem with gem cache.

Comment 10 by honglilai, Sep 07 (46 hours ago)

At this time I suspect that the gem metadata files have somehow became corrupted. Whether that is the fault of REE remains to be seen; for now some more information from people who can reproduce the problem is required.

To those who can reproduce the problem, could you verify that all the .gem files that are cached by Bundler are valid? .gem files are actually just tar files; if you unpack them with tar that should give you two .gz files, data.tar.gz and metadata.gz. Can you try to decompress both files and check that neither give errors?

Do things work again after deleting the cached .gem files?

The problem I am seeing is not a problem with a corrupt cached Gem. Deleting the Gem caches and Bundle artifacts directories was one of the first things we tried.

The error that is being discussed is a general purpose error that is thrown when tar_input.rb can't read a Gem. It may be that the Gem just isn't there at all, or in the case of me and the OP, it seems that REE is messing up the allocation of where it thinks the in-memory objects are. Have another read of the OP, because doing the no-op like he did as a work-around worked for me too. Which indicated to me straight away that it's not a corrupt Gem problem.

We keep our gem cache in Git, so it can't be corrupted that easily anyway. We check it out onto a Vanilla Ruby machine and bundle install works fine, check out the same onto an REE machine and it breaks every time. We removed all external sources in the Gemfile, so there is no chance of a new, corrupted Gem being downloaded to the cache.

Finally, we first encountered this problem after a increase in the number of Gems listed in our Gemfile. If we remove 5-6 key dependencies from the Gemfile, the problem goes away too. This of course isn't a solution, we use all the Gems we list.

@jonathan.hoskin If you could provide access to this setup that "breaks every time", that would be extremely helpful. I've run into this bug several times in the past, but am having a hard time reproducing reliably which makes tracking it down and fixing it quite hard.

It appears that the problem is caused by compiler optimizations. Recompiling the zlib extension without optimizations seems to solve the problem so far.

Hi guys,

I am able to reliably reproduce this problem.

Here is some of my system information: bundler (1.0.7) Mac OS (10.6.5) REE (1.8.7-2010.02)

When I start up a new terminal and run bundle install it fails. Then when I set this environment variable: export RUBY_HEAP_MIN_SLOTS=500000 It consistently installs just fine.

I just noticed this problem, and just noticed that this workaround consistently works. I don't know how long I will continue to be able to reproduce it, but with my current setup, I can reproduce it, and "fix" it consistently every time.

I hope this information helps debugging the issue. Let me know if there is anything else I can do to help.

This confirms what I have seen as well, in pointing to a GC related issue. I can replicate 100% of the time by adding a GC.stress=true to the Gemfile, however it takes more than 30 minutes to run bundler in this configuration.

So after many many hours of debugging, I was able to create a repro for this issue. The repro also triggers the bug in regular unpatched ruby, meaning this is not a REE specific bug.

To reproduce (note that results on OSX are inconsistent, but any ruby 1.8 on Linux will fail with this repro right away):

unless File.exists?("rake-0.8.7.gem")
  puts 'downloading rake gem...'
  require 'open-uri'
  File.open('rake-0.8.7.gem','w'){|f| f.write open("http://production.cf.rubygems.org/gems/rake-0.8.7.gem").read }
end

require 'zlib'
require 'rubygems/format'

class Zlib::GzipReader
  class << self
    alias new_orig new
    def new(*args)
      GC.stress=true
      new_orig(*args)
    ensure
      GC.stress=false
    end
  end
end

def parse_gem
  Gem::Format.from_file_by_path('rake-0.8.7.gem')
end
1000.times do |i|
  p [Time.now, i+1]
  parse_gem
end

Turns out this was already discovered and fixed upstream in ruby 1.9, so we simply need to get the patch applied to 1.8 as well. The next release of REE can include this simple patch: https://github.com/ruby/ruby/commit/1887f60a8540f64f5c7bb14d57c0be70506941b8

Note that you can also repro this with the following change to zlib.c, in place of the monkey-patch that enables GC.stress=true

diff --git a/ext/zlib/zlib.c b/ext/zlib/zlib.c
index 306e267..db00f22 100644
--- a/ext/zlib/zlib.c
+++ b/ext/zlib/zlib.c
@@ -601,6 +601,7 @@ zstream_append_input(z, src, len)

     if (NIL_P(z->input)) {
    z->input = rb_str_buf_new(len);
+   rb_gc();
    rb_str_buf_cat(z->input, src, len);
    RBASIC(z->input)->klass = 0;
     }

Nice! Good work!

Issue 37 has been merged into this issue.

Issue 29 has been merged into this issue.

Comment deleted