January 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:111577] [Ruby master Bug#19299] YJIT panicked while holding VM lock acquired at ./yjit/src/core.rs:1693. Aborting...
by ollym (Oliver Morgan) 25 Jan '23

25 Jan '23

Issue #19299 has been reported by ollym (Oliver Morgan). ---------------------------------------- Bug #19299: YJIT panicked while holding VM lock acquired at ./yjit/src/core.rs:1693. Aborting... https://bugs.ruby-lang.org/issues/19299 * Author: ollym (Oliver Morgan) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Attached is the backtrace. The code is a moderately complex view with partials and translations. The panic happens specifically when i call a translation `t('...')` but if i simplify the view code around that call the panic goes away. I'm trying to create a simplified way to recreate it without giving you the full application. I'll keep trying, unless the backtrace is enough. ---Files-------------------------------- backtrace.txt (12.3 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112032] [Ruby master Feature#16012] Add a (small) test-install suite?
by Eregon (Benoit Daloze) 25 Jan '23

25 Jan '23

Issue #16012 has been updated by Eregon (Benoit Daloze). I think this could become part of ruby/spec, and then we'd run ruby/spec on both built and on installed CRuby with chkbuild. ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-101466 * Author: MSP-Greg (Greg L) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112031] [Ruby master Feature#16012] Add a (small) test-install suite?
by Eregon (Benoit Daloze) 25 Jan '23

25 Jan '23

Issue #16012 has been updated by Eregon (Benoit Daloze). FYI there is this script to check bin/ files, which could be reused: https://github.com/ruby/ruby-dev-builder/blob/master/cli_test.rb ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-101465 * Author: MSP-Greg (Greg L) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112029] [Ruby master Bug#10919] [gem install] installs multipe platforms
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #10919 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Third Party's Issue @abaumgaertner Can you file this to https://github.com/rubygems/rubygems? ---------------------------------------- Bug #10919: [gem install] installs multipe platforms https://bugs.ruby-lang.org/issues/10919#change-101463 * Author: abaumgaertner (Andreas Baumgaertner) * Status: Third Party's Issue * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49761) [x64-mingw32] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- Natively build a gem - just an example mysql2 on windows x64-mingw32 I could only get the gem to compile with devkit when --platform=ruby is specified - so my understanding is that all devkit compiled gems are platform ruby, even if devkit platform is acutally x64-mingw32 ~~~ C:\apps\redmine_dev\bin>gem install mysql2 --no-document --platform=ruby -- "--with-mysql-dir=c:/apps/redmine_dev/mysql-5.6.23-winx64" Fetching: mysql2-0.3.18.gem (100%) Temporarily enhancing PATH to include DevKit... Building native extensions with: '--with-mysql-dir=c:/apps/redmine_dev/mysql-5.6.23-winx64' This could take a while... Successfully installed mysql2-0.3.18 1 gem installed ~~~ here comes the acutal issue: rerun (also with other dependency managers e.g. bundle install) installs dupplicate gem for platform x64-mingw32 ~~~ C:\apps\redmine_dev\bin>gem install mysql2 Fetching: mysql2-0.3.18-x64-mingw32.gem (100%) ====================================================================================================== \ You've installed the binary version of mysql2. It was built using MySQL Connector/C version 6.1.5. It's recommended to use the exact same version to avoid potential issues. At the time of building this gem, the necessary DLL files were retrieved from: http://cdn.mysql.com/Downloads/Connector-C/mysql-connector-c-6.1.5-winx64.z… \ This gem *includes* vendor/libmysql.dll with redistribution notice in vendor/README. ====================================================================================================== Successfully installed mysql2-0.3.18-x64-mingw32 Parsing documentation for mysql2-0.3.18-x64-mingw32 Installing ri documentation for mysql2-0.3.18-x64-mingw32 Done installing documentation for mysql2 after 0 seconds 1 gem installed ~~~ what is the point in installing a gem for two platforms? it is also not supported by require to specify a platform. solution a: gem install should not install an additional platform, if the gem is already present gem list should always display the platform (not only if there are more than 1) solution b: add an option to gem install that forces devkit build for specific platform so gem install will recognize that the platform is already present. ~~~ C:\apps\redmine_dev\bin>gem list *** LOCAL GEMS *** bundler (1.8.3) mysql2 (0.3.18 ruby x64-mingw32) ~~~ ~~~ C:\apps\redmine_dev\bin>gem env RubyGems Environment: - RUBYGEMS VERSION: 2.4.5 - RUBY VERSION: 2.2.1 (2015-02-26 patchlevel 85) [x64-mingw32] - INSTALLATION DIRECTORY: C:/apps/redmine_dev/ruby/lib/ruby/gems/2.2.0 - RUBY EXECUTABLE: C:/apps/redmine_dev/ruby/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/apps/redmine_dev/ruby/bin - SPEC CACHE DIRECTORY: C:/Users/abaumgaertner/.gem/specs - SYSTEM CONFIGURATION DIRECTORY: C:/ProgramData - RUBYGEMS PLATFORMS: - ruby - x64-mingw32 - GEM PATHS: - C:/apps/redmine_dev/ruby/lib/ruby/gems/2.2.0 - C:/Users/abaumgaertner/.gem/ruby/2.2.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - https://rubygems.org/ - SHELL PATH: - C:\apps\redmine_dev\ruby\bin - C:\apps\redmine_dev\libs - C:\apps\redmine_dev\ImageMagick - D:\apps\mercurial_dev - d:\msys64\mingw64\bin - d:\msys64\mingw64\lib - d:\msys64\usr\bin - C:\Windows\system32 - C:\Windows - C:\Windows\System32\Wbem - C:\Windows\System32\WindowsPowerShell\v1.0\ ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112028] [Ruby master Feature#16012] Add a (small) test-install suite?
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #16012 has been updated by hsbt (Hiroshi SHIBATA). I'm considering this request again. I'll add small check into https://github.com/ruby/chkbuild. ---------------------------------------- Feature #16012: Add a (small) test-install suite? https://bugs.ruby-lang.org/issues/16012#change-101462 * Author: MSP-Greg (Greg L) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- At various times there has been discussion about whether testing should require `make install`. Although I prefer to do testing using install (vs build), I see it as a choice, and not a requirement. From time to time various issues have arisen that cannot be found with 'build' testing. Often, these issues cause CI test failure with master/trunk/ruby-head in external repos. Sometimes people blame 'Core', other times Travis, or rvm. Regardless, it doesn't look good. So, might a small set of tests that check install functionality be added? It may need to be two separate (but equivalent) scripts. One for *nix, one for Windows. In ruby-loco, I'm using a ps1 script to check that CLI bin files work. As soon as the update is pushed here, I'll add a test for nested bundler commands... -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112027] [Ruby master Feature#13534] Checking installation results of default gems
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #13534 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed I move this to https://bugs.ruby-lang.org/issues/16012. ---------------------------------------- Feature #13534: Checking installation results of default gems https://bugs.ruby-lang.org/issues/13534#change-101459 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- It's a reminder. I merged rubygems-2.6.12 at r58530. But it backports was removed `test_realworld_default_gem` from original release. Because `test_realworld_default_gem` verifies installation results of default gems. So ruby test suite is not supported after `make install` environment. Therefore, We should add test suite of `tool/rbinstall.rb`for default gems/bundled gems/rdoc etc. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112026] [Ruby master Feature#6590] Dealing with bigdecimal, etc gems in JRuby
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #6590 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Third Party's Issue We can work bigdecimal for JRuby like * https://github.com/ruby/psych (psych contained java implementation and publish jar file) or * https://github.com/ruby/date (date contained empty file for JRuby) or other approach. We should move this issue to https://github.com/ruby/bigdecimal/issues/169. ---------------------------------------- Feature #6590: Dealing with bigdecimal, etc gems in JRuby https://bugs.ruby-lang.org/issues/6590#change-101458 * Author: headius (Charles Nutter) * Status: Third Party's Issue * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Hello! http://jira.codehaus.org/browse/JRUBY-6704 We have a need to make the "bigdecimal" gem work for JRuby, so that distros (like Red Hat, mentioned in the above bug) and users can have the same gemspec for JRuby with updated bigdecimal gem references. I'm not sure the best way to proceed. The bigdecimal source and gemspec all come from MRI source, and are not versioned separately. That means we can't simply share a repository for the JRuby bits. We could maintain a forked version in our forked "jruby/ruby" repository, but that wouldn't be part of the bigdecimal release cycle then. So I'm looking to you for guidance. The BigDecimal lib is here in JRuby: https://github.com/jruby/jruby/tree/master/src/org/jruby/ext/bigdecimal It might be simplest if for now there's a dummy "bigdecimal" gem pushed for JRuby that does not contain anything, since we would have other complications if we tried to remove BigDecimal from JRuby proper (it is referenced elsewhere int eh code, etc). Thoughts? - Charlie ---Files-------------------------------- noname (500 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112025] [Ruby master Bug#18355] require("pathname") within rack application chnages behaviors of Pathname methods, such as absolute?(), when there are two versions of 'pathname' gem installed.
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #18355 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Feedback Can you try it with the latest version of RubyGems/Bundler? You can do it with: ``` $ gem update --system ``` ---------------------------------------- Bug #18355: require("pathname") within rack application chnages behaviors of Pathname methods, such as absolute?(), when there are two versions of 'pathname' gem installed. https://bugs.ruby-lang.org/issues/18355#change-101457 * Author: ume-san (Toshi Umehara) * Status: Feedback * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Environment Ruby 3.0.2 is installed on Fedora 34 from source. 'gem update' is conducted, and there are two versions of 'pathname' gems (0.2.0, default: 0.1.0) installed as follows. ``` > uname -a Linux localhost.localdomain 5.14.18-200.fc34.x86_64 #1 SMP Fri Nov 12 16:48:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] > gem update --system > gem update > gem list ... pathname (0.2.0, default: 0.1.0) ... ``` ## Code The following files, Gemfile and config.ru, are placed in the same directory. ``` # Gemfile source 'https://rubygems.org/' gem 'rack' gem 'webrick' ``` ``` # config.ru class Application def call(env) status = 200 headers = { "Content-Type" => "text/html" } path = Dir.pwd() pathname1 = Pathname.new(path) require("pathname") pathname2 = Pathname.new(path) body = ["#{pathname1.absolute?} #{pathname2.absolute?}"] [status, headers, body] end end run Application.new ``` ## Command Web server starts using the following commands. ``` bundle config set --local path 'vendor/bundle' bundle install bundle exec rackup -s webrick ``` * Output on the console ``` [2021-11-21 09:44:13] INFO WEBrick 1.7.0 [2021-11-21 09:44:13] INFO ruby 3.0.2 (2021-07-07) [x86_64-linux] [2021-11-21 09:44:13] INFO WEBrick::HTTPServer#start: pid=2770 port=9292 ``` ## Expected Result Accessing localhost:9292 using a web browser , 'true true' is an expected result on the browser, because pathname1 and pathanme2 are generated from the same absolute path in the above code. ``` true true ``` ## Actual Result Accessing localhost:9292 shows the following messages on the browser and the console. After 'require("pathname")', Pathname.absolute?() retuns false, even if represents an absolute path. * On the browser ``` true false ``` * On the console ``` /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:20: warning: already initialized constant Pathname::TO_PATH /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:20: warning: previous definition of TO_PATH was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:22: warning: already initialized constant Pathname::SAME_PATHS /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:22: warning: previous definition of SAME_PATHS was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:34: warning: already initialized constant Pathname::SEPARATOR_LIST /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:34: warning: previous definition of SEPARATOR_LIST was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:35: warning: already initialized constant Pathname::SEPARATOR_PAT /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:35: warning: previous definition of SEPARATOR_PAT was here /home/toshihiro/Ruby3/lib/ruby/3.0.0/pathname.rb:41: warning: already initialized constant Pathname::ABSOLUTE_PATH /home/toshihiro/Ruby3/lib/ruby/gems/3.0.0/gems/pathname-0.2.0/lib/pathname.rb:41: warning: previous definition of ABSOLUTE_PATH was here 127.0.0.1 - - [21/Nov/2021:09:44:20 +0900] "GET / HTTP/1.1" 200 10 0.0339 ``` ## Segmentation fault Moreover, press Ctrl-c to stop the Rack application, the application causes a segmentation fault. The segmentation fault message is attached. ## Notes Uninstalling version 0.2.0 of pathname gem solves the problem above. Therefore, I guess having two versions of pathname gems causes this behavior. ``` gem uninstall pathname --version=0.2.0 ``` * Start the Rack application again ``` bundle exec rackup -s webrick ``` * Output on the browser The expected output is obtained on the browser, without warning messages on the console. ``` true true ``` ---Files-------------------------------- segmentation_fault.txt (51.1 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111813] [Ruby master Bug#19341] Write cache issue with class variables
by luke-gru (Luke Gruber) 25 Jan '23

25 Jan '23

Issue #19341 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19341: Write cache issue with class variables https://bugs.ruby-lang.org/issues/19341 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` ruby class SetCvar def self.set(val) @@a = val # inline cache end end def test_set_cvar_on_frozen_object SetCvar.set(1) # fill write cache SetCvar.freeze SetCvar.set(2) # hit write cache, but should check frozen status end test_set_cvar_on_frozen_object() ``` PR Here: https://github.com/ruby/ruby/pull/7124 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111529] [Ruby master Bug#19289] RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby
by Eregon (Benoit Daloze) 25 Jan '23

25 Jan '23

Issue #19289 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19289: RbConfig::CONFIG["STRIP"] should keep `rb_abi_version` and `rb_abi_version` should always be part of Ruby https://bugs.ruby-lang.org/issues/19289 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From https://github.com/grpc/grpc/pull/31970 and https://github.com/redis-rb/redis-client/issues/58 First, I think we could add `-K rb_abi_version` to `RbConfig::CONFIG["STRIP"]` so it's automatically kept if `RbConfig::CONFIG["STRIP"]` is used (and that should be used if one strips any native extension). Second, I think it would be much better if the symbol is kept also for releases. The check could be kept too for safety (e.g., it can detect Ruby 3.3.0 gems used by Ruby 3.2.0), the value of `rb_abi_version` would just be the same as `RbConfig::CONFIG["ruby_version"]`, i.e., 3.2.0 for Ruby 3.2.x. Any difference between dev and release builds is a risk of not properly testing the release, and there is proof here that removing the symbol in releases causes troubles. Doing both of these would avoid complex and brittle logic upstream as in grpc and redis-client to deal with the new symbol. cc @nobu @peterzhu2118 -- https://bugs.ruby-lang.org/

4 7