Closed spaquet closed 4 months ago
@deivid-rodriguez Would that be related to the same sort of problem that digest had? https://github.com/ruby/openssl/pull/463#event-5461640109
It seems similar to https://github.com/ruby/fileutils/issues/22 too. I'll need a repro to look at it, are spring
or bootsnap
involved?
My builds are failing with the same error from yesterday i have to stop the pathname gem from update. is there anything i can do for this not to fail.
LOCAL GEMS
pathname (0.2.0, default: 0.1.0)
/usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:20: warning: already initialized constant Pathname::TO_PATH
/usr/local/bundle/gems/pathname-0.2.0/lib/pathname.rb:20: warning: previous definition of TO_PATH was here
/usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:22: warning: already initialized constant Pathname::SAME_PATHS
/usr/local/bundle/gems/pathname-0.2.0/lib/pathname.rb:22: warning: previous definition of SAME_PATHS was here
/usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:34: warning: already initialized constant Pathname::SEPARATOR_LIST
/usr/local/bundle/gems/pathname-0.2.0/lib/pathname.rb:34: warning: previous definition of SEPARATOR_LIST was here
/usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:35: warning: already initialized constant Pathname::SEPARATOR_PAT
/usr/local/bundle/gems/pathname-0.2.0/lib/pathname.rb:35: warning: previous definition of SEPARATOR_PAT was here
/usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:41: warning: already initialized constant Pathname::ABSOLUTE_PATH
/usr/local/bundle/gems/pathname-0.2.0/lib/pathname.rb:41: warning: previous definition of ABSOLUTE_PATH was here
/usr/local/bundle/ruby/3.0.0/gems/pry-byebug-3.8.0/lib/pry-byebug/control_d_handler.rb:5: warning: control_d_handler's arity of 2 parameters was deprecated (eval_string, pry_instance). Now it gets passed just 1 parameter (pry_instance)
/usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:49:in `basename': no implicit conversion of nil into String (TypeError)
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:49:in `chop_basename'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/3.0.0/pathname.rb:332:in `ascend'
from /usr/local/bundle/ruby/3.0.0/gems/ffi-compiler-1.0.1/lib/ffi-compiler/loader.rb:11:in `find'
from /usr/local/bundle/ruby/3.0.0/gems/llhttp-ffi-0.0.1/lib/llhttp.rb:13:in `<module:LLHttp>'
from /usr/local/bundle/ruby/3.0.0/gems/llhttp-ffi-0.0.1/lib/llhttp.rb:6:in `<top (required)>'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `block in require'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:299:in `load_dependency'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/http-5.0.0/lib/http/response/parser.rb:3:in `<top (required)>'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `block in require'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:299:in `load_dependency'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/http-5.0.0/lib/http.rb:16:in `<top (required)>'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `block in require'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:299:in `load_dependency'
from /usr/local/bundle/ruby/3.0.0/gems/activesupport-6.1.3.2/lib/active_support/dependencies.rb:332:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/noticed-1.4.1/lib/noticed.rb:2:in `<top (required)>'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler/runtime.rb:60:in `require'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler/runtime.rb:60:in `block (2 levels) in require'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler/runtime.rb:55:in `each'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler/runtime.rb:55:in `block in require'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler/runtime.rb:44:in `each'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler/runtime.rb:44:in `require'
from /usr/lib/fullstaq-ruby/versions/3.0.1-jemalloc/lib/ruby/site_ruby/3.0.0/bundler.rb:174:in `require'
from /app/config/application.rb:7:in `<top (required)>'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/command/actions.rb:22:in `require'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/command/actions.rb:22:in `require_application!'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/command/actions.rb:14:in `require_application_and_environment!'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/commands/console/console_command.rb:101:in `perform'
from /usr/local/bundle/ruby/3.0.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run'
from /usr/local/bundle/ruby/3.0.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command'
from /usr/local/bundle/ruby/3.0.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/command/base.rb:69:in `perform'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/command.rb:50:in `invoke'
from /usr/local/bundle/ruby/3.0.0/gems/railties-6.1.3.2/lib/rails/commands.rb:18:in `<top (required)>'
from ./bin/rails:9:in `require'
from ./bin/rails:9:in `<main>'
Just to clarify, in my case the builds are not failing, but it's annoying... It's also triggered when I open the rails console. Let me review the 2 issues you reported above to let you know if I find a fix to this problem.
My environment: ruby 3.0.1 rails 6.1.4
spring is commented out in my Gemfile, but bootsnap is not gem 'bootsnap', '>= 1.4.4', require: false
https://github.com/ruby/fileutils/issues/22 seems to be close to the issue I reported. So I tried few things such as gem update --system 3.2.3 && gem update --system
but that does not change the problem so far.
App is working, but these errors messages when lauching the console or the app are quite annoying.
I just tried removing bootsnap
but that does not change anything.
@spaquet can you try gem list pathname
what is it returning if it is returning something like this pathname (0.2.0, default: 0.1.0)
try gem uninstall pathname
which would uninstall 0.2.0 and the warnings should disappear. this is what worked for me.
It sounds like it is going to be hard to get a repro, so here's some steps you can take to provide me with some more information about the issue:
$ fd pathname.rb$ ~/.rbenv/versions/3.0.2
/Users/deivid/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb
/Users/deivid/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb
puts "=================================== backtrace =================================="
puts caller_locations(0).join("\n")
puts "================================================================================"
Before updating to v0.2.0 (so, just the default gem v0.1.0), there is only: ~/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb
.
After updating, we have the following:
~/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb
~/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb
A diff of the two files:
~/.rbenv/versions/3.0.2/lib/ruby$ diff 3.0.0/pathname.rb gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb
577a578,579
> autoload(:FileUtils, 'fileutils')
>
582,584c584,585
< def mkpath
< require 'fileutils'
< FileUtils.mkpath(@path)
---
> def mkpath(mode: nil)
> FileUtils.mkpath(@path, mode: mode)
594d594
< require 'fileutils'
A plain IRB session (no bundler) gives no warnings:
irb(main):001:0> require 'pathname'
=> true
If IRB is started by creating a new, basic gem with bundle gem
and running either bundle exec irb
or bundle console
, it will print the warnings, and upon exiting IRB there is a segfault. I've uploaded a gist with the coredumps for these two cases here.
If I use the bin/console
binstub that bundler creates when generating the gem, the same warnings still print. However, the segfault does NOT occur upon exiting IRB.
Even if I add IRB to the bundle, generate a binstub for IRB, and require 'pathname'
the same way as before, the warnings print but there is no segfault. Adding other gems and running the generated binstubs for those such as bin/rubocop
will cause the segfault however.
I realize I haven't found the exact issue yet, but I'll keep digging later; hopefully what I've found so far can be of use.
A segfault is surprising and it should probably be reported to ruby-core.
Regarding the warning, can you show a backtrace of the require point of each file (write the snippet above into each of the involved pathname.rb
files and share the output).
Oh oops, I didn't read your comment right at first, so I didn't realize you wanted the backtrace lines inserted into the actual lib files, my bad. Otherwise, I would have included that in my first reply. Here's another gist with the backtraces on; I've also included the outputs of gem env
there, as well as bundle env
for the basic gem I used in the examples that used bundler. Let me know if there's anything else I can do to help!
Oh, I see what the problem is now.
When bundler/setup
is required, some relevant things happen in the following order:
pathname
is required by bundler, and the pathname
gem is activated, because rubygems
require is in place here, and it automatically activates the highest version of default gems present in the system. In this case, pathname 0.2.0 is activated.
Then, in order to setup the load path to only include gems specified in the Gemfile, bundler first cleans paths from activated gems from the $LOAD_PATH
, removing ~/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib
from it.
Then bundler "unmonkeypatches" rubygems require
going back ruby's default require
which only searches the $LOAD_PATH
without any extra magic to activate gems, because we know the exact paths of all gems that we need (the ones in the Gemfile{,.lock}
).
Finally bundler puts the paths of the exact set of gems specified in the Gemfile{,.lock}
into the $LOAD_PATH
.
As a consequence, by the time pathname
is required the second time, the $LOAD_PATH
no longer includes ~/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib
and ruby's default require
is used this time, resulting in the default version of pathname
(~/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb
) being loaded this time, and the redefinition warnings triggered.
We need to refactor bundler
internals to not require pathname
so early, and by doing that we'll fix this issue, but also add support for pathname
to be specified in the Gemfile
, which is not yet supported.
I'll work on this tomorrow.
Well, these warnings are so annoying (e.g.: showing up for each rake task) that I rolled back to the default pathname-0.1.0 with a cursory gem uninstall pathname
@deivid-rodriguez isn't that course of action just going to make the same problem reappear later with a different gemified library? Would it be possible to change the behavior of Bundler instead, e.g., by not having it remove the paths for gems that have already been activated? I realize there will be consequences to that too, of course.
Yes, that would probably fix this particular situation and it might be a good move in any case, but it still wouldn't allow users to specify pathname
in the Gemfile
. It would result in an error if the version chosen by the user via Gemfile
differs from the version required by bundler internally.
We usually solve this problem by making bundler
not activate any gems, by vendoring the gems that we use under our own module, like Bundler::Pathname
, and using that instead. That's what I'm implementing in rubygems/rubygems#4992 (this one is particularly tricky because the gem has a C-extension, and because bundler uses it quite heavily).
@sumankula yes. This fixes the issue. However you also go back to the previous version ;-) that's a quick "hack" to remove the warning messages, but does not fixe the problem for the version 0.2.0
Sorry for being a bit slow I was caught on another project. Here is my backtrace as requested for pathname 0.2.0
=================================== backtrace ==================================
/Users/username/.rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:17:in `<class:Pathname>'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:15:in `<main>'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails.rb:5:in `<main>'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
/Users/username/Sites/ProjectX/main-app/config/application.rb:4:in `<main>'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails/command/actions.rb:22:in `require_application!'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails/command/actions.rb:14:in `require_application_and_environment!'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails/commands/console/console_command.rb:101:in `perform'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails/command/base.rb:69:in `perform'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails/command.rb:48:in `invoke'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4.1/lib/rails/commands.rb:18:in `<main>'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
bin/rails:5:in `<main>'
================================================================================
and here are the first 21 lines of the application.rb file:
require_relative "boot"
# require "rails/all"
require "rails" <- line 4
# Pick the frameworks you want:
require "active_model/railtie"
require "active_job/railtie"
require "active_record/railtie"
require "active_storage/engine"
require "action_controller/railtie"
require "action_mailer/railtie"
require "action_mailbox/engine"
require "action_text/engine"
require "action_view/railtie"
require "action_cable/engine"
# require "sprockets/railtie"
require "rails/test_unit/railtie"
# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)
Here is the backtrace for pathname 0.1.0 as a reference point
=================================== backtrace ==================================
/Users/username/.rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:17:in `<class:Pathname>'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:15:in `<top (required)>'
<internal:/Users/username/.rbenv/versions/3.0.1/lib/ruby/site_ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
<internal:/Users/username/.rbenv/versions/3.0.1/lib/ruby/site_ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
/Users/username/.rbenv/versions/3.0.1/lib/ruby/site_ruby/3.0.0/bundler.rb:4:in `<top (required)>'
<internal:/Users/username/.rbenv/versions/3.0.1/lib/ruby/site_ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
<internal:/Users/username/.rbenv/versions/3.0.1/lib/ruby/site_ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
/Users/username/Sites/ProjectX/main-app/bin/spring:4:in `<top (required)>'
bin/rails:2:in `load'
bin/rails:2:in `<main>'
================================================================================
Thank you @spaquet, my PR in rubygems should fix the issue, I'll try to wrap it up soon.
Hi!
I'm seeing a lot of similar warnings from URI as well as pathname, is https://github.com/ruby/pathname/issues/12#issuecomment-945198245 likely to be the cause?
Examples (truncated for brevity):
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/uri/version.rb:3: warning: already initialized constant URI::VERSION_CODE
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/uri-0.11.0/lib/uri/version.rb:3: warning: previous definition of VERSION_CODE was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/uri/version.rb:4: warning: already initialized constant URI::VERSION
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/uri-0.11.0/lib/uri/version.rb:4: warning: previous definition of VERSION was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/uri/rfc2396_parser.rb:28: warning: already initialized constant URI::RFC2396_REGEXP::PATTERN::ALPHA
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/uri-0.11.0/lib/uri/rfc2396_parser.rb:28: warning: previous definition of ALPHA was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/uri/rfc2396_parser.rb:30: warning: already initialized constant URI::RFC2396_REGEXP::PATTERN::ALNUM
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/uri-0.11.0/lib/uri/rfc2396_parser.rb:30: warning: previous definition of ALNUM was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/uri-0.11.0/lib/uri/rfc3986_parser.rb:7: warning: previous definition of RFC3986_relative_ref was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/uri/common.rb:16: warning: already initialized constant URI::REGEXP
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/uri-0.11.0/lib/uri/common.rb:16: warning: previous definition of REGEXP was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/uri/common.rb:17: warning: already initialized constant URI::Parser
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb:20: warning: already initialized constant Pathname::TO_PATH
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:20: warning: previous definition of TO_PATH was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb:22: warning: already initialized constant Pathname::SAME_PATHS
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:22: warning: previous definition of SAME_PATHS was here
/Users/tarragon/.rbenv/versions/3.0.2/lib/ruby/3.0.0/pathname.rb:34: warning: already initialized constant Pathname::SEPARATOR_LIST
The underlying cause is the same: a new version of default gems used by bundler/rubygems internally has been released (in this case, uri-0.11.0), potentially causing two versions of the same gem to be activated at the same time. Solution is also to vendor uri
inside bundler/rubygems.
I'm trying to run kitchen tests and I segfault with pathname-0.2.0.
/home/linuxbrew/.linuxbrew/lib/ruby/gems/3.0.0/gems/bundler-2.2.31/lib/bundler/shared_helpers.rb:58: [BUG] Segmentation fault at 0x0000000000000008
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]
If I gem uninstall pathname
my kitchen test run with pathname-0.1.0 however I see all the warning messages as the OP mentions.
I'm running on a fresh WSL2 ubuntu install setting up my env like so:
# Ruby
brew install ruby
echo 'export RUBYOPT="-W:no-deprecated -W:no-experimental"' >> ~/.zshrc
echo 'gem: --no-document' > ~/.gemrc
cat << EOF > ~/Gemfile
source "https://rubygems.org/"
source "https://rubygems.org/" do
gem "kitchen-terraform"
gem "inspec"
gem "inspec-bin"
gem "rubocop"
gem "cookstyle"
end
EOF
echo 'export BUNDLE_GEMFILE="~/Gemfile"' >> ~/.zshrc
source ~/.zshrc
gem install bundle
gem update
bundle update
If this is a problem outside the scope of this repo and my info may be useful, can you point me to the correct place?
@brettcurtis Please separate your SEGV issues from this? It seems to the difference.
@hsbt - done! https://github.com/ruby/pathname/issues/14
Can someone having this issue (or #14, I believe it's the same after all) verify that this little patch to bundler fixes things:
diff --git a/bundler/lib/bundler/shared_helpers.rb b/bundler/lib/bundler/shared_helpers.rb
index 405ade95dd..846b9cc3aa 100644
--- a/bundler/lib/bundler/shared_helpers.rb
+++ b/bundler/lib/bundler/shared_helpers.rb
@@ -313,12 +313,11 @@ def bundler_ruby_lib
end
def clean_load_path
- bundler_lib = bundler_ruby_lib
-
loaded_gem_paths = Bundler.rubygems.loaded_gem_paths
$LOAD_PATH.reject! do |p|
- next if resolve_path(p).start_with?(bundler_lib)
+ resolved_path = resolve_path(p)
+ next if $LOADED_FEATURES.any? {|lf| lf.start_with?(resolved_path) }
loaded_gem_paths.delete(p)
end
$LOAD_PATH.uniq!
@deivid-rodriguez - I'm back in business with that patch - Thanks !
Bundler 2.2.33 has been released which I expect to fix this issue. I think this can be closed.
"Works on my Laptop" :D Thanks for the fix!
Bundler 2.2.33 has been released which I expect to fix this issue. I think this can be closed.
bundle update --bundler
Great! Thanks for this fix!
Updating bundler fixed this for me. Thanks for the fix.
Since upgrading to version 0.2.0 a lot of warning messages are popping up when launching an app or the console.
.rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:20: warning: already initialized constant Pathname::TO_PATH .rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:20: warning: previous definition of TO_PATH was here .rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:22: warning: already initialized constant Pathname::SAME_PATHS .rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:22: warning: .rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:34: warning: already initialized constant Pathname::SEPARATOR_LISTprevious definition of SEPARATOR_LIST was here .rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:35: warning: already initialized constant .rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:35: warning: .rbenv/versions/3.0.1/lib/ruby/3.0.0/pathname.rb:41: warning: already initialized constant Pathname::ABSOLUTE_PATH previous definition of ABSOLUTE_PATH was here
Anybody else with the same warnings?