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

[ruby-core:115804] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by matz (Yukihiro Matsumoto) 20 Dec '23

20 Dec '23

Issue #18915 has been updated by matz (Yukihiro Matsumoto). #note-13 explains my opinion well. What name candidate do you have? Matz. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105753 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115779] [Ruby master Bug#20072] free(): invalid pointer when compiled with --enable-shared --with-jemalloc
by misdoro (Mikhail Doronin) 20 Dec '23

20 Dec '23

Issue #20072 has been reported by misdoro (Mikhail Doronin). ---------------------------------------- Bug #20072: free(): invalid pointer when compiled with --enable-shared --with-jemalloc https://bugs.ruby-lang.org/issues/20072 * Author: misdoro (Mikhail Doronin) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-08-17T01:57:09Z test 5bb9462285) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When ruby is built with `--enable-shared --with-jemalloc` on Linux (current Gentoo, ubuntu22 in docker), running a rails app yields: ``` free(): invalid pointer Aborted ``` The issue started appearing after 5bb946228550c7f171c27725860b153a675404f3 https://github.com/ruby/ruby/commit/5bb946228550c7f171c27725860b153a675404f3 Related to https://bugs.ruby-lang.org/issues/18409 (workaround to LD_PRELOAD jemalloc from that issue works) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:115800] [Ruby master Feature#13383] [PATCH] Module#source_location
by matz (Yukihiro Matsumoto) 20 Dec '23

20 Dec '23

Issue #13383 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected I don't think “natural” is not a good reason for adding a new method, especially regarding open class/module definitions. I am not against if the feature is proposed for the debugger. Matz. ---------------------------------------- Feature #13383: [PATCH] Module#source_location https://bugs.ruby-lang.org/issues/13383#change-105746 * Author: koba789 (Hidekazu Kobayashi) * Status: Rejected * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- # Abstract It can inspect where the module or class is defined. # Background In debugging or development an application, I usually want to find out where the class definition of using library. There is Method#source_location but I could not find **Class** easily. # Implementation In Github: https://github.com/ruby/ruby/pull/1562 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113572] [Ruby master Bug#19683] ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby
by jeremyevans0 (Jeremy Evans) 19 Dec '23

19 Dec '23

Issue #19683 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19683: ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby https://bugs.ruby-lang.org/issues/19683 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [x86_64-openbsd7.3] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ruby-3.3.0-preview1 does not build with BSD make without `--with-baseruby`. However, it builds fine with GNU make and when using BSD make with `--with-baseruby`. Previous Ruby tarball releases have built fine with BSD make without `--with-baseruby`, so this issue has been introduced recently. When building with BSD make without `--with-baseruby`, building fails after generating RI format with: ``` /bin/sh: false: not found *** Error 127 in . (exts.mk:94 'ruby': @make UPDATE_LIBRARIES=no EXTENCS=dmyenc.o BASERUBY=echo\ executable\ host\ ruby\ is\ required.\ \ ...) *** Error 2 in /home/jeremy/local/ruby-3.3.0-preview1 (Makefile:948 'build-ext': @make -f exts.mk libdir="/usr/local/lib" LIBRUBY_EXTS=./...) ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115412] [Ruby master Bug#20008] f(**kw, &block) calls block.to_proc before kw.to_hash
by jeremyevans0 (Jeremy Evans) 19 Dec '23

19 Dec '23

Issue #20008 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20008: f(**kw, &block) calls block.to_proc before kw.to_hash https://bugs.ruby-lang.org/issues/20008 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-12 master 60e19a0b5f) [x86_64-openbsd] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The evaluation order expectation is that `kw.to_hash` is called first in this case. Ruby previously called `kw.to_hash` before `block.to_proc` in Ruby 2, but stopped doing so in Ruby 3.0. In master, `f(*a, **kw, &block)` is also affected. However, that is not true in Ruby 3.2 and earlier (though Ruby 2.0 and 2.1 called `kw.to_hash` before `a.to_a`). The reason for the current behavior is that `vm_caller_setup_arg_block` calls `block.to_proc` before `vm_sendish` is called. `kw.to_hash` is not called until `CALLER_SETUP_ARG` or `setup_parameters_complex`. I have a pull request that fixes this (https://github.com/ruby/ruby/pull/8877) by adding a `splatkw` VM instruction and calling it directly before any send instructions that have both `VM_CALL_ARGS_BLOCKARG` and `VM_CALL_KW_SPLAT` and not `VM_CALL_KW_SPLAT_MUT`. The `splatkw` instruction calls `kw.to_hash` if `kw` is not already a Hash. The `splatkw` instruction is not needed for mutable keyword splats, as `kw.to_hash` would have already been called by earlier instructions in that case. It is possible to fix this without a new VM instruction, by adding the logic to `vm_caller_setup_arg_block` or `rb_vm_send`. However, then an additional check is needed in every method call, instead of only before method calls that actually need it. I would guess that approach would be slower, though as I have not benchmarked that approach, it is not an educated guess. Currently, the `splatkw` instruction is inserted using the peephole optimizer. I'm not sure if using the optimizer to fix bugs is acceptable. If not, it could probably be moved to the compiler proper. I do not believe we should backport this fix, as I consider a new VM instruction invasive, and the benefit of backporting seems small. Example code: ```ruby o = Object.new o.define_singleton_method(:to_hash) {p :called_to_hash; {}} o.define_singleton_method(:to_proc) {p :called_to_proc; lambda{}} puts "p(**o, &o)" p(**o, &o) ``` Actual Output: ``` p(**o, &o) :called_to_proc :called_to_hash ``` Expected Output: ``` p(**o, &o) :called_to_hash :called_to_proc ``` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:115793] [Ruby master Bug#20073] Method lookup incorrect with `--parser=prism`
by eightbitraptor (Matthew Valentine-House) 19 Dec '23

19 Dec '23

Issue #20073 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #20073: Method lookup incorrect with `--parser=prism` https://bugs.ruby-lang.org/issues/20073 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following code works with both CRuby's compiler and Prism when evaluated using `RubyVM::InstructionSequence` ``` ~/git/ruby master ≡ ❯ ./miniruby -d -e'p RubyVM::InstructionSequence.compile_prism("tap { }").eval' main ~/git/ruby master ≡ ❯ ./miniruby -d -e'p RubyVM::InstructionSequence.compile("tap { }").eval' main ``` However when using the command line `--parser=prism` flag it results in a `NoMethodError` attempting to find `tap`, whereas CRuby's parser does not. ``` ~/git/ruby master ≡ ❯ ./miniruby -d -e'p tap { }' main ~/git/ruby master ≡ ❯ ./miniruby --parser=prism -d -e'p tap { }' ./miniruby: warning: The compiler based on the Prism parser is currently experimental and compatibility with the compiler based on parse.y is not yet complete. Please report any issues you find on the `ruby/prism` issue tracker. Exception `NoMethodError' at <compiled> - undefined method `tap' for main <compiled>:in `<compiled>': undefined method `tap' for main (NoMethodError) ``` This appears to be because the toplevel binding context is not being prepended to the linked list of instruction sequences when `--parser=prism` is passed. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115751] [Ruby master Bug#20067] IO.pipe `int_enc` and `ext_enc` not working as documented?
by byroot (Jean Boussier) 19 Dec '23

19 Dec '23

Issue #20067 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20067: IO.pipe `int_enc` and `ext_enc` not working as documented? https://bugs.ruby-lang.org/issues/20067 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From the documentation: > pipe(ext_enc, int_enc, **opts) > If argument int_enc is given, it must be an Encoding object or encoding name string that specifies the internal encoding to be used; if argument ext_enc is also given, it must be an Encoding object or encoding name string that specifies the external encoding to be used. Test script: ```ruby ios = IO.pipe(Encoding::BINARY, Encoding::BINARY) p [:internal, *ios.map(&:internal_encoding)] p [:external, *ios.map(&:external_encoding)] Encoding.default_internal = Encoding::UTF_8 Encoding.default_external = Encoding::UTF_8 ios = IO.pipe(Encoding::BINARY, Encoding::BINARY) p [:internal, *ios.map(&:internal_encoding)] p [:external, *ios.map(&:external_encoding)] ``` Actual output: ``` [:internal, nil, nil] [:external, #<Encoding:ASCII-8BIT>, nil] [:internal, nil, nil] [:external, #<Encoding:ASCII-8BIT>, #<Encoding:UTF-8>] ``` Expected output: ``` [:internal, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] [:external, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] [:internal, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] [:external, #<Encoding:ASCII-8BIT>, #<Encoding:ASCII-8BIT>] ``` Am I reading the documentation incorrectly, or is it just not working as claimed? I tried on older versions, and it seems to have been like that all the way down to Ruby 1.9. The only reliable way I found to have a "binary" pipe is to call `IO#binmode`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 19 Dec '23

19 Dec '23

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

5 9

[ruby-core:115328] [Ruby master Bug#19996] `RUBY_MN_THREADS=1` triggers Action Cable unit test failures
by yahonda (Yasuo Honda) 19 Dec '23

19 Dec '23

Issue #19996 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #19996: `RUBY_MN_THREADS=1` triggers Action Cable unit test failures https://bugs.ruby-lang.org/issues/19996 * Author: yahonda (Yasuo Honda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-09T16:24:15Z :detached: c49adfab5d) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ### Steps to reproduce 1. Install `ruby 3.3.0dev` 2. Set `RUBY_MN_THREADS=1` environment variable 3. git clone https://github.com/rails/rails cd rails rm Gemfile.lock bundle install cd actioncable bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 ``` ### Expected behavior It should pass as not setting ``` $ unset RUBY_MN_THREADS $ bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m which will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 14800 # Running: ......................................................................... Finished in 12.031310s, 6.0675 runs/s, 46.7115 assertions/s. 73 runs, 562 assertions, 0 failures, 0 errors, 0 skips $ ``` ### Actual behavior It usually fails as follows. ``` $ bin/test test/channel/base_test.rb test/subscription_adapter/redis_test.rb test/channel/test_case_test.rb test/subscription_adapter/redis_test.rb test/client_test.rb --seed 14800 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/minitest-5.20.0/lib/minitest.rb:3: warning: mutex_m which will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec. Run options: --seed 14800 # Running: ..................................................F Failure: RedisAdapterTest::AlternateConfiguration#test_channel_prefix [/home/yahonda/src/github.com/rails/rails/actioncable/test/subscription_adapter/common.rb:35]: Expected #<Concurrent::Event:0x00007f0b2698d4f0 @__Lock__=#<Thread::Mutex:0x00007f0b26f8cab8>, @__Condition__=#<Thread::ConditionVariable:0x00007f0b26f8ca90>, @set=false, @iteration=0> to be set?. bin/test test/subscription_adapter/channel_prefix.rb:6 .F Failure: RedisAdapterTest::AlternateConfiguration#test_multiple_broadcast [/home/yahonda/src/github.com/rails/rails/actioncable/test/subscription_adapter/common.rb:35]: Expected #<Concurrent::Event:0x00007f0b2698a4d0 @__Lock__=#<Thread::Mutex:0x00007f0b26fac688>, @__Condition__=#<Thread::ConditionVariable:0x00007f0b26fac4f8>, @set=false, @iteration=0> to be set?. bin/test test/subscription_adapter/common.rb:74 E Error: ClientTest#test_interacting_clients: ThreadError: queue empty <internal:thread_sync>:18:in `pop' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:168:in `read_message' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:241:in `block (2 levels) in test_interacting_clients' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `block (2 levels) in concurrently' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1583:in `evaluate_to' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1766:in `block in on_resolvable' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:352:in `run_task' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:343:in `block (3 levels) in create_worker' <internal:kernel>:187:in `loop' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:334:in `block (2 levels) in create_worker' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `catch' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:333:in `block in create_worker' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1258:in `raise' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:1258:in `wait_until_resolved!' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/concurrent-ruby-1.2.2/lib/concurrent-ruby/concurrent/promises.rb:988:in `value!' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `map' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:218:in `concurrently' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:240:in `block in test_interacting_clients' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:90:in `with_puma_server' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:234:in `test_interacting_clients' bin/test test/client_test.rb:233 E Error: ClientTest#test_disappearing_client: ThreadError: queue empty <internal:thread_sync>:18:in `pop' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:168:in `read_message' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:275:in `block in test_disappearing_client' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:90:in `with_puma_server' /home/yahonda/src/github.com/rails/rails/actioncable/test/client_test.rb:273:in `test_disappearing_client' bin/test test/client_test.rb:272 .................. Finished in 1323.812615s, 0.0551 runs/s, 0.3830 assertions/s. 73 runs, 507 assertions, 2 failures, 2 errors, 0 skips $ ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115635] [Ruby master Bug#20045] `TestDir#test_home` fails on i686
by vo.x (Vit Ondruch) 19 Dec '23

19 Dec '23

Issue #20045 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20045: `TestDir#test_home` fails on i686 https://bugs.ruby-lang.org/issues/20045 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [i686-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This is followup to #19147. Testing on Fedora 38 and Fedora Rawhide, we are facing this test failure: ~~~ $ tar xf build/SOURCES/ruby-3.2.2.tar.xz $ cd ruby-3.2.2/ $ ./configure && make ... snip ... --- Configuration summary for ruby version 3.2.2 * Installation prefix: /usr/local * exec prefix: ${prefix} * arch: i686-linux * site arch: ${arch} * RUBY_BASE_NAME: ruby * ruby lib prefix: ${libdir}/${RUBY_BASE_NAME} * site libraries path: ${rubylibprefix}/${sitearch} * vendor path: ${rubylibprefix}/vendor_ruby * target OS: linux * compiler: gcc * with thread: pthread * with coroutine: x86 * enable shared libs: no * dynamic library ext: so * CFLAGS: ${optflags} ${debugflags} ${warnflags} * LDFLAGS: -L. -fstack-protector-strong -rdynamic -Wl,-export-dynamic * DLDFLAGS: -Wl,--compress-debug-sections=zlib * optflags: -O3 -fno-fast-math * debugflags: -ggdb3 * warnflags: -Wall -Wextra -Wdeprecated-declarations -Wdiv-by-zero -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wwrite-strings -Wold-style-definition \ -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat \ -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wundef * strip command: strip -S -x * install doc: rdoc * MJIT support: yes * YJIT support: no * man page type: doc --- ... snip ... $ LANG=C make test-all 'TESTS=-v -n /TestDir#test_home/' config.status: creating ruby-runner.h making mjit_build_dir.so generating i686-linux-fake.rb i686-linux-fake.rb updated Run options: --seed=10517 "--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/excludes --name=!/memory_leak/ -v -n /TestDir#test_home/ # Running tests: [1/0] TestDir#test_home = 0.00 s 1) Error: TestDir#test_home: RuntimeError: can't set length of shared string /builddir/ruby-3.2.2/test/ruby/test_dir.rb:557:in `expand_path' /builddir/ruby-3.2.2/test/ruby/test_dir.rb:557:in `block in test_home' Finished tests in 4.164691s, 0.2401 tests/s, 1.6808 assertions/s. 1 tests, 7 assertions, 0 failures, 1 errors, 0 skips ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [i686-linux] make: *** [uncommon.mk:855: yes-test-all] Error 1 ~~~ Please note that having the `C` locale is essential. The test passes just fine with e.g. `C.UTF-8` locale. We were able to reduce the test case to the following: ~~~ $ whoami mockbuild $ echo 'File.expand_path("~mockbuild")' > test.rb $ LANG=C RUBYLIB=/builddir/ruby-3.2.2/.ext/i686-linux LD_LIBRARY_PATH=. ./ruby --disable-gems test.rb test.rb:1:in `expand_path': can't set length of shared string (RuntimeError) from test.rb:1:in `<main>' ~~~ As I said earlier, the `LANG=C` is essential as well as the `RUBYLIB=/builddir/ruby-3.2.2/.ext/i386-linux`. Adding the path to `RUBYLIB` enables Ruby to load the following libraries: ~~~ /builddir/ruby-3.2.2/.ext/i686-linux/enc/encdb.so /builddir/ruby-3.2.2/.ext/i686-linux/enc/trans/transdb.so ~~~ And that makes the difference. Also, the `File.expand_path("~mockbuild")` must be in some file, replacing this by `-e 'File.expand_path("~mockbuild")'` does not reproduce the issue. We also believe that this was introduced by https://github.com/ruby/ruby/pull/6699, specifically by commit:git|5246f4027ec574e77809845e1b1f7822cc2a5cef and fixed in master by commit:git|b4571097df4a6bd848f1195026d82a92f3a7f9d8. Unfortunately, we were not able to discover what is the mechanism behind this, why this depends on locale, why the test must be in file, why the string is shared etc. But I hope we have provided enough details for someone else more knowledgeable. Some background for this issue is also available here: https://src.fedoraproject.org/rpms/ruby/pull-request/164 -- https://bugs.ruby-lang.org/

2 2