Bundler 2.3.7 causing uninitialized constant Gem::Source and CRITICAL: RUBYGEMS_ACTIVATION_MONITOR.owned?: before false -> after true errors #5351
Comments
|
Definitely broken by 31bba75. Not fully sure why though, a reproducible case would be very helpful, I guess it's related to some gems RVM installs by default and that hook too much into bundler internals. I think you can workaround this by removing the |
|
Also you can try upgrading RubyGems through |
|
@deivid-rodriguez Thank you for identifying that so quickly. I have long-wondered whether Does I did try |
|
We have been working on providing this functionality inside RubyGems/Bundler, specifically by setting the In any case, if you prefix your commands with |
|
Thanks for that context, I've been wondering for a while what was the original use-case for some of those gems especially as they seemed dated (while at the same time being part of RVM's install). To answer your earlier point, indeed once I uninstall rubygems-bundler and executable-hooks: things work again. I'll plan to look to see if we can remove those gems as part of our RVM installation and that we're not relying on that particular behaviour unintentionally. |
|
If you happen to be able to provide a small example to reproduce this, I'd be happy to have a closer look. Unfortunately all RVM users get these gems by default, so we should probably revert the change but it'd be nice to cover the revert with some test to ensure that I don't cause the same trouble again in the future. |
|
|
|
Yes, we already identified the change that removed the require and caused this issue. But I don't fully understand why it happened because RubyGems should be autoloading I will have a closer look to find a reproducible case, and regardless of that I will revert the change. |
|
I have the same problem after upgrade rubygems to latest using
|
|
Sorry I forgot about this, I will ship this revert with the next version (2.3.9) |
Bundler 2.3.7 caused issues: - rubygems/rubygems#5351 - #1280 Internal (private) tickets: - https://heroku.support/1083230 - https://heroku.support/1081495 - https://heroku.support/1082829 I've already rolled back the build pack deploy via the buildpack CLI. This commit is intended to represent the currently deployed software accurately in the codebase.
Bundler 2.3.7 caused issues: - rubygems/rubygems#5351 - #1280 Internal (private) tickets: - https://heroku.support/1083230 - https://heroku.support/1081495 - https://heroku.support/1082829 I've already rolled back the build pack deploy via the buildpack CLI. This commit is intended to represent the currently deployed software accurately in the codebase.
|
It appears this issue has a resolution already, but I didn't see the requested small reproduction case, so I thought I'd offer mine in case it is helpful. I am able to reproduce this issue with this script. Downgrading to Bundler v2.3.6 resolves the issue. Notably, I do not use RVM. Instead, I rely on Rbenv. Here is my EnvironmentBundler Build MetadataBundler settings |
|
Thank you, no not yet, we know the culprit and I will revert the offending commit for 2.3.9, but having a reproducible case is very useful so that we can cover the fix with a regression spec. Thanks so much! |
|
@shawnacscott I can not reproduce the issue using the same Ruby, RubyGems, Bundler and Rbenv version that you are using. Can you share the list of gems you have installed locally? ( |
|
Alright, I managed to reproduce this locally using I'll try to reproduce this error in CI, so that it fails without the revert. |
|
Alright I managed to reproduce this error in CI: https://github.com/rubygems/rubygems/runs/5455765474?check_suite_focus=true. Tomorrow I will get the fix ready! |
|
Getting this error on bundler 2.3.8 and rubygems 3.3.8 - no RVM etc, Ruby 2.5.8 compiled straight from source. Happens in |
|
Thank you so much for addressing this issue, even though the underlying issue is caused by an older gem and not part of Rubygems's own distribution! |
|
No problem @timsutton! In the end the issue turned out to be more widespread and reproducible without this RVM old gem. That made it more clear that we needed to address this :) |
|
For me renaming the Gemfile.lock to Gemfile.lock.copy, running bundle install and then removing the Gemfile.lock.copy |
@briancolfer , thanks for the tips! It worked perfectly for me. |
|
I guess people are having issues to upgrade bundler when they run into this issue. Does |
Running this fixed it for me @deivid-rodriguez |
|
Did the trick for me |
|
The recommended solution is What you did @Keltz-dev also works but note that all of your dependencies were also upgraded, since you regenerated the |
|
Thanks Guys. I just encountered the same issue |
|
Thanks Guys :) |
Without this, I was getting an error `uninitialized constant Gem::Source`. This thread suggested I update bundler and it totally fixed it: rubygems/rubygems#5351 (comment)
Without this, I was getting an error `uninitialized constant Gem::Source`. This thread suggested I update bundler and it totally fixed it: rubygems/rubygems#5351 (comment)
Without this, I was getting an error `uninitialized constant Gem::Source`. This thread suggested I update bundler and it totally fixed it: rubygems/rubygems#5351 (comment)
Describe the problem as clearly as you can
I've observed that when we have
gem installedthe latest bundler 2.3.7 version, that it causes a rubygems crash when I attempt to invoke a bin exe of a small internal gem. We aren't using bundler to invoke the gem, however I guessed that this is at least in some way related to Bundler as I can't reproduce it when 2.3.6 is installed.Did you try upgrading rubygems & bundler?
I did not. The reason is that I can only reproduce this on our Mac CI machines, which use RVM to provide Ruby 2.7.x. RubyGems on this version is currently at 3.1.6.
I can still try this to see if the problem goes away, but I wanted to get this issue logged first since the
CRITICAL: RUBYGEMS_ACTIVATION_MONITOR.owned?: before false -> after true (RuntimeError)error struck me as something definitely unexpected.Post steps to reproduce the problem
I can work on more specific repro cases for this but I don't have anything immediately to share - I might need to find some small "exemplar" gem as an internal example. This gem has one dependency but that gem is also internal. I have not yet tried to find other public gems that might exhibit this same issue.
The system is:
gem install bundlerBundler 2.1.4 happens to be the 'default' version, but
bundlecommands do use the latest version installed, and I do seebundler-2.3.7library paths as part of the traceback in the error I've included below.Which command did you run?
Here's a sample of how I'd invoke our internal gem:
I have tried the same thing with explicitly setting 2.7.4 to be the RVM default via
rvm use 2.7.4 --defaultand then omitting thervm 2.7.4 docommands, just to eliminate this as a variable.It's installed here:
The bin exe was installed originally via:
What were you expecting to happen?
I would normally just get our gem exe's help output, i.e.
What actually happened?
These are other bundler versions I had installed:
What is interesting is that if I remove 2.3.7 like this:
... the command works fine. I can then put it back via
gem install bundler -v.2.3.7, and will get the same error/traceback again.If not included with the output of your command, run
bundle envand paste the output belowEnvironment
Bundler Build Metadata
The text was updated successfully, but these errors were encountered: