bundle:install failing with: bignum too big to convert into `long' (RangeError) (still exists) #637

Closed
jgeiger opened this Issue Aug 31, 2010 · 11 comments

Projects

None yet

3 participants

@jgeiger
Contributor
jgeiger commented Aug 31, 2010

This just happened to me. Doesn't matter if I use the default task or not, and it fails when running directly on the server by hand.

Command:
bundle install --deployment --gemfile Gemfile --without test cucumber

Error:
/usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in hash': bignum too big to convert intolong' (RangeError)
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in hash' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:inhash'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler.rb:227:in inject' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:ineach'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in inject' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:inhash'
from /usr/local/lib/ruby/1.8/tsort.rb:182:in include?' from /usr/local/lib/ruby/1.8/tsort.rb:182:ineach_strongly_connected_component'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/spec_set.rb:124:in tsort_each_node' from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/spec_set.rb:124:ineach'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/spec_set.rb:124:in tsort_each_node' from /usr/local/lib/ruby/1.8/tsort.rb:181:ineach_strongly_connected_component'
from /usr/local/lib/ruby/1.8/tsort.rb:149:in tsort_each' from /usr/local/lib/ruby/1.8/tsort.rb:136:intsort'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/spec_set.rb:107:in sorted' from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/spec_set.rb:12:ineach'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/installer.rb:44:in run' from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/installer.rb:8:ininstall'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/cli.rb:217:in install' from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/vendor/thor/task.rb:22:insend'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/vendor/thor/task.rb:22:in run' from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/vendor/thor/invocation.rb:118:ininvoke_task'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/vendor/thor.rb:246:in dispatch' from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/lib/bundler/vendor/thor/base.rb:389:instart'
from /usr/local/lib/ruby/gems/1.8/gems/bundler-1.0.0/bin/bundle:13
from /usr/local/bin/bundle:19:in `load'
from /usr/local/bin/bundle:19

@wycats
Contributor
wycats commented Sep 1, 2010

Last time we saw this, it was a serialization issue (a modification we had made to Rubygems was causing problems). That's likely the issue again, but I'm unsure what modifications could be involved.

@jgeiger
Contributor
jgeiger commented Sep 1, 2010

Sorry, not sure I provided a lot of information last time. Here are some things that might help.

edit: had to quote the revisions in the Gemfile lock so it wouldn't auto-replace

development machine
Darwin macbook 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]

dev deploy server info
Linux something 2.6.18-194.8.1.el5 # 1 SMP Wed Jun 23 10:58:38 EDT 2010 i686 athlon i386 GNU/Linux
ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-linux]

prod deploy server info
Linux server 2.6.18-164.11.1.el5 # 1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
ruby 1.8.7 (2009-12-24 patchlevel 248) [x86_64-linux]

deploy server gem list
-bash-3.2$ gem list

*** LOCAL GEMS ***

bundler (1.0.0)
fastthread (1.0.7)
mysql (2.8.1)
passenger (2.2.15)
rack (1.2.1)
rake (0.8.7)
right_aws (2.0.0)
right_http_connection (1.2.4)
rubygems-update (1.3.7)
rubyzip (0.9.4)

Gemfile
source 'http://rubygems.org'

gem 'rails', '3.0.0'

gem 'mysql2'
gem 'agraph', :require => 'allegro_graph'

gem 'haml'

gem 'warden'
gem 'devise', :git => "git://github.com/plataformatec/devise.git", :branch => "v1.1"
gem 'bcrypt-ruby', :require => 'bcrypt'
gem "oauth2"

gem "will_paginate", '~>3.0.pre2'

gem 'admin_data'
gem 'jammit', :git => "http://github.com/documentcloud/jammit.git"

group :development do
  gem "rspec-rails", "~> 2.0.0.beta.20"
end

group :test, :cucumber do
  # bundler requires these gems while running tests
  gem 'capybara'
  gem 'database_cleaner'
  gem 'cucumber-rails'
  gem 'cucumber'
  gem 'spork'
  gem 'launchy'    # So you can do Then show me the page
  gem 'webrat'
  gem "rspec", "~> 2.0.0.beta.20"
  gem "rspec-rails", "~> 2.0.0.beta.20"
end

Gemfile.lock
GIT
remote: git://github.com/plataformatec/devise.git
revision: "56834284bdaf4a1dbb2ee7b238d8c099be7ac2a1"
branch: v1.1
specs:
devise (1.1.2)
bcrypt-ruby (> 2.1.2)
warden (
> 0.10.7)

GIT
  remote: http://github.com/documentcloud/jammit.git
  revision: "8f934928d6228147e86db483c59d2d2a23f3732f"
  specs:
    jammit (0.5.1)
      closure-compiler (>= 0.1.0)
      yui-compressor (>= 0.9.1)

GEM
  remote: http://rubygems.org/
  specs:
    abstract (1.0.0)
    actionmailer (3.0.0)
      actionpack (= 3.0.0)
      mail (~> 2.2.5)
    actionpack (3.0.0)
      activemodel (= 3.0.0)
      activesupport (= 3.0.0)
      builder (~> 2.1.2)
      erubis (~> 2.6.6)
      i18n (~> 0.4.1)
      rack (~> 1.2.1)
      rack-mount (~> 0.6.12)
      rack-test (~> 0.5.4)
      tzinfo (~> 0.3.23)
    activemodel (3.0.0)
      activesupport (= 3.0.0)
      builder (~> 2.1.2)
      i18n (~> 0.4.1)
    activerecord (3.0.0)
      activemodel (= 3.0.0)
      activesupport (= 3.0.0)
      arel (~> 1.0.0)
      tzinfo (~> 0.3.23)
    activeresource (3.0.0)
      activemodel (= 3.0.0)
      activesupport (= 3.0.0)
    activesupport (3.0.0)
    addressable (2.2.0)
    admin_data (1.0.9)
      will_paginate (>= 3.0.pre2)
    agraph (0.1.1)
    arel (1.0.1)
      activesupport (~> 3.0.0)
    bcrypt-ruby (2.1.2)
    builder (2.1.2)
    capybara (0.3.9)
      culerity (>= 0.2.4)
      mime-types (>= 1.16)
      nokogiri (>= 1.3.3)
      rack (>= 1.0.0)
      rack-test (>= 0.5.4)
      selenium-webdriver (>= 0.0.3)
    closure-compiler (0.3.2)
    configuration (1.1.0)
    cucumber (0.8.5)
      builder (~> 2.1.2)
      diff-lcs (~> 1.1.2)
      gherkin (~> 2.1.4)
      json_pure (~> 1.4.3)
      term-ansicolor (~> 1.0.4)
    cucumber-rails (0.3.2)
      cucumber (>= 0.8.0)
    culerity (0.2.12)
    database_cleaner (0.5.2)
    diff-lcs (1.1.2)
    erubis (2.6.6)
      abstract (>= 1.0.0)
    faraday (0.4.6)
      addressable (>= 2.1.1)
      rack (>= 1.0.1)
    ffi (0.6.3)
      rake (>= 0.8.7)
    gherkin (2.1.5)
      trollop (~> 1.16.2)
    haml (3.0.18)
    i18n (0.4.1)
    json_pure (1.4.6)
    launchy (0.3.7)
      configuration (>= 0.0.5)
      rake (>= 0.8.1)
    mail (2.2.5)
      activesupport (>= 2.3.6)
      mime-types
      treetop (>= 1.4.5)
    mime-types (1.16)
    multi_json (0.0.4)
    mysql2 (0.2.3)
    nokogiri (1.4.3.1)
    oauth2 (0.0.13)
      faraday (~> 0.4.1)
      multi_json (>= 0.0.4)
    polyglot (0.3.1)
    rack (1.2.1)
    rack-mount (0.6.13)
      rack (>= 1.0.0)
    rack-test (0.5.4)
      rack (>= 1.0)
    rails (3.0.0)
      actionmailer (= 3.0.0)
      actionpack (= 3.0.0)
      activerecord (= 3.0.0)
      activeresource (= 3.0.0)
      activesupport (= 3.0.0)
      bundler (~> 1.0.0)
      railties (= 3.0.0)
    railties (3.0.0)
      actionpack (= 3.0.0)
      activesupport (= 3.0.0)
      rake (>= 0.8.4)
      thor (~> 0.14.0)
    rake (0.8.7)
    rspec (2.0.0.beta.20)
      rspec-core (= 2.0.0.beta.20)
      rspec-expectations (= 2.0.0.beta.20)
      rspec-mocks (= 2.0.0.beta.20)
    rspec-core (2.0.0.beta.20)
    rspec-expectations (2.0.0.beta.20)
      diff-lcs (>= 1.1.2)
    rspec-mocks (2.0.0.beta.20)
    rspec-rails (2.0.0.beta.20)
      rspec (= 2.0.0.beta.20)
    rubyzip (0.9.4)
    selenium-webdriver (0.0.28)
      ffi (>= 0.6.1)
      json_pure
      rubyzip
    spork (0.8.4)
    term-ansicolor (1.0.5)
    thor (0.14.0)
    treetop (1.4.8)
      polyglot (>= 0.3.1)
    trollop (1.16.2)
    tzinfo (0.3.23)
    warden (0.10.7)
      rack (>= 1.0.0)
    webrat (0.7.1)
      nokogiri (>= 1.2.0)
      rack (>= 1.0)
      rack-test (>= 0.5.3)
    will_paginate (3.0.pre2)
    yui-compressor (0.9.1)

PLATFORMS
  ruby

DEPENDENCIES
  admin_data
  agraph
  bcrypt-ruby
  capybara
  cucumber
  cucumber-rails
  database_cleaner
  devise!
  haml
  jammit!
  launchy
  mysql2
  oauth2
  rails (= 3.0.0)
  rspec (~> 2.0.0.beta.20)
  rspec-rails (~> 2.0.0.beta.20)
  spork
  warden
  webrat
  will_paginate (~> 3.0.pre2)
@jgeiger
Contributor
jgeiger commented Sep 1, 2010

It also seems that before I ran into that issue I tried installing the bundle on top of the existing code.

I got an error
An error has occurred in git when running `git reset --hard 56834284bdaf4a1dbb2ee7b238d8c099be7ac2a1. Cannot complete bundling.

This is the sha from devise, v1.1, and I'm going to see if I update the git for devise to master if it will properly deploy.

Updated to devise/master head
* executing "cd /www/servers/qtlhighlighter/current; bundle install --gemfile Gemfile --deployment --quiet --without test cucumber"
servers: ["server.edu"]
[server.edu] executing command
** [out :: server.edu] fatal: Could not parse object '6e71eca2ddc2e6fa4e8f3b74f03233c7c03bffab'.
** [out :: server.edu] An error has occurred in git when running `git reset --hard 6e71eca2ddc2e6fa4e8f3b74f03233c7c03bffab. Cannot complete bundling.
command finished

After blowing away my shared/bundled_gems directory I was able to deploy properly to my production (64bit) server, but the dev server (32bit) still crashes.

@wycats
Contributor
wycats commented Sep 3, 2010

This looks to be a Rubygems issue (http://rubyforge.org/tracker/index.php?func=detail&aid=27154&group_id=126&atid=575). The reason it works on 64 bit but not 32 bit is likely that Bignums are bigger in 64 bits, so there's a lot more space to app up hash components. They should fix this in 1.3.8.

@jgeiger
Contributor
jgeiger commented Sep 3, 2010

Actually further checking up the stack shows that it's an error in ruby MRI itself and was patched sometime in 2009. The version of 1.8.7 I was using was p72 which was 2008-08-11. Updating to the newest version solves the issue. Thanks again.

@cayblood

Anyone know why this bug doesn't happen in rvm-installed ree-1.8.6 but it does happen in the debian pkg version of ree-1.8.6? I have a legacy rails app that won't work with 1.8.7 that I am very close to getting working if not for this annoying bug. Would like to run it on lucid32 if possible.

@wycats
Contributor
wycats commented Feb 24, 2012

What version of rubygems are you using in each case?

@cayblood

I'm using rubygems 1.3.7 in both cases.

@wycats
Contributor
wycats commented Feb 24, 2012

If you read the comments above, you'll find that 1.3.7 had a bug that caused this problem, and was fixed in the next version. It was somewhat mitigated by 64-bit versions of Ruby, which could hold a larger runaway hash value. Is one of your rubies 32-bit and one 64-bit?

@cayblood

Eric Hodel said on his blog that the next version (1.4.0) did not support ruby 1.8.6. Also, I've tried rubygems 1.4.0 and it seemed still to have this problem.

@cayblood

My solution was simply to patch

lib/ruby/site_ruby/1.8/rubygems/requirement.rb

as follows:

674,676c674,675
<     @@attributes.inject(0) { |hash_code, (name, default_value)|
<       n = self.send(name).hash
<       hash_code + n
---
>     @@attributes.inject(612553) { |hash_code, (name, default_value)|
>       hash_code ^ self.send(name).to_s.hash

The to_s is hacky and probably inefficient but it works for my limited purposes. It was calling a number of different classes' hash methods, some of which are buggy, so I forced everything to a string representation before hashing.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment