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

[ruby-core:115459] [Ruby master Bug#20017] 3.3.0dev `rb_thread_profile_frames` crashes when `RUBY_MN_THREADS=1`
by byroot (Jean Boussier) 20 Dec '23

20 Dec '23

Issue #20017 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20017: 3.3.0dev `rb_thread_profile_frames` crashes when `RUBY_MN_THREADS=1` https://bugs.ruby-lang.org/issues/20017 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.3.0dev (2023-11-19T03:01:05Z shopify 9aee12cc28) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I discovered this while running our internal CI with MaNy enabled, our application crash when trying to profile with StackProf (with postponed jobs disabled): ``` [BUG] Segmentation fault at 0x0000000000000010 ruby 3.3.0dev (2023-11-19T03:01:05Z shopify 9aee12cc28) +MN [x86_64-linux] -- C level backtrace information ------------------------------------------- /usr/local/ruby/bin/ruby(rb_print_backtrace+0x14) [0x55c8f16333e1] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/vm_dump.c:812 /usr/local/ruby/bin/ruby(rb_vm_bugreport) /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/vm_dump.c:1143 /usr/local/ruby/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x55c8f17e559c] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/error.c:1065 /usr/local/ruby/bin/ruby(sigsegv+0x4d) [0x55c8f158091d] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/signal.c:920 /lib/x86_64-linux-gnu/libc.so.6(0x7ff3db333520) [0x7ff3db333520] /usr/local/ruby/bin/ruby(thread_profile_frames+0x10) [0x55c8f162efd0] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/vm_backtrace.c:1587 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_buffer_sample+0x28) [0x7ff3b7d2435c] /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:622 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_buffer_sample) /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:604 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_buffer_sample) (null):0 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler+0x5) [0x7ff3b7d24545] /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:767 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler) /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:722 /lib/x86_64-linux-gnu/libc.so.6(0x7ff3db333520) [0x7ff3db333520] /lib/x86_64-linux-gnu/libc.so.6(pthread_cond_wait+0x24a) [0x7ff3db384a7a] /usr/local/ruby/bin/ruby(rb_native_cond_wait+0xb) [0x55c8f15c8cbb] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/thread_pthread.c:214 /usr/local/ruby/bin/ruby(ractor_sched_deq) /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/thread_pthread.c:1230 /usr/local/ruby/bin/ruby(nt_start) /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/thread_pthread.c:2209 ``` For additional context, as far as I know `rb_thread_profile_frames` isn't officially async signal safe, but it happens to be since 3.0 for the interpreter, and 3.3 for YJIT, so StackProf tries not to use postponed jobs for profiling when it can as it leads to much more accurate profiling results. Ref: https://github.com/tmm1/stackprof/issues/221 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115458] [Ruby master Bug#20016] 3.3.0dev `rb_postponed_job_register_one` crashes when `RUBY_MN_THREADS=1`
by byroot (Jean Boussier) 20 Dec '23

20 Dec '23

Issue #20016 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20016: 3.3.0dev `rb_postponed_job_register_one` crashes when `RUBY_MN_THREADS=1` https://bugs.ruby-lang.org/issues/20016 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.3.0dev (2023-11-22T17:01:13Z shopify c1fc1a00ea) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I discovered this while running our internal CI with MaNy enabled, our application crash when trying to profile with StackProf: ``` [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.0dev (2023-11-22T17:01:13Z shopify c1fc1a00ea) +MN [x86_64-linux] -- Machine register context ------------------------------------------------ RIP: 0x000055df5fe38489 RBP: 0x00007f517bc59000 RSP: 0x00007f5123f3c6d0 RAX: 0x0000000000000000 RBX: 0x00007f51596554e0 RCX: 0x00007f517bdb6b40 RDX: 0x0000000000000001 RDI: 0x00007f517bc59000 RSI: 0x0000000000000000 R8: 0x0000000000000000 R9: 0x00000000ffffffff R10: 0x0000000000000000 R11: 0x0000000000000246 R12: 0x0000000000000000 R13: 0x0000000000000000 R14: 0x0000000000001ea5 R15: 0x00007f517bc59104 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /usr/local/ruby/bin/ruby(rb_print_backtrace+0x14) [0x55df5fe328e1] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_dump.c:812 /usr/local/ruby/bin/ruby(rb_vm_bugreport) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_dump.c:1143 /usr/local/ruby/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x55df5ffe509c] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/error.c:1065 /usr/local/ruby/bin/ruby(sigsegv+0x4d) [0x55df5fd7f19d] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/signal.c:920 /lib/x86_64-linux-gnu/libc.so.6(0x7f517c277520) [0x7f517c277520] /usr/local/ruby/bin/ruby(rbimpl_atomic_or+0x0) [0x55df5fe38489] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1691 /usr/local/ruby/bin/ruby(postponed_job_register) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1693 /usr/local/ruby/bin/ruby(postponed_job_register) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1675 /usr/local/ruby/bin/ruby(rb_postponed_job_register_one) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1746 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler+0x2d) [0x7f5159655434] /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:763 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler) /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:722 /lib/x86_64-linux-gnu/libc.so.6(0x7f517c277520) [0x7f517c277520] /lib/x86_64-linux-gnu/libc.so.6(0x7f517c2c6117) [0x7f517c2c6117] /lib/x86_64-linux-gnu/libc.so.6(pthread_cond_wait+0x211) [0x7f517c2c8a41] /usr/local/ruby/bin/ruby(rb_native_cond_wait+0xb) [0x55df5fdc75fb] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/thread_pthread.c:214 /usr/local/ruby/bin/ruby(ractor_sched_deq) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/thread_pthread.c:1230 /usr/local/ruby/bin/ruby(nt_start) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/thread_pthread.c:2209 /lib/x86_64-linux-gnu/libc.so.6(0x7f517c2c9ac3) [0x7f517c2c9ac3] ``` Ref: https://github.com/tmm1/stackprof/issues/221 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112262] [Ruby master Feature#19422] Make `--enabled-shared` mandatory on macOS
by nobu (Nobuyoshi Nakada) 20 Dec '23

20 Dec '23

Issue #19422 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #19422: Make `--enabled-shared` mandatory on macOS https://bugs.ruby-lang.org/issues/19422 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- From the troubles around linker on macOS, I propose `--enable-shared` option mandatory on macOS. This patch enables the option by default, and abort if `--disable-shared` option is given explicitly. ```diff diff --git i/configure.ac w/configure.ac index 7db2ab5257c..923ac7d1199 100644 --- i/configure.ac +++ w/configure.ac @@ -504,6 +504,11 @@ AS_CASE(["$target_os"], rb_cv_binary_elf=no : ${enable_shared=yes} ], +[darwin*], [ + AS_IF([test "${enable_shared=yes}" = no], [ + AC_MSG_ERROR([--disable-shared is not supported on this platform]) + ]) +], [hiuxmpp*], [AC_DEFINE(__HIUX_MPP__)]) # by TOYODA Eizi <toyoda(a)npd.kishou.go.jp> AC_PROG_LN_S @@ -3055,14 +3060,7 @@ AC_SUBST(EXTOBJS) : ${LDFLAGS=""} : ${LIBPATHENV=DYLD_FALLBACK_LIBRARY_PATH} : ${PRELOADENV=DYLD_INSERT_LIBRARIES} - AS_IF([test x"$enable_shared" = xyes], [ - # Resolve symbols from libruby.dylib when --enable-shared - EXTDLDFLAGS='$(LIBRUBYARG_SHARED)' - ], [test "x$EXTSTATIC" = x], [ - # When building exts as bundles, a mach-o bundle needs to know its loader - # program to bind symbols from the ruby executable - EXTDLDFLAGS="-bundle_loader '\$(BUILTRUBY)'" - ]) + EXTDLDFLAGS='$(LIBRUBYARG_SHARED)' rb_cv_dlopen=yes], [aix*], [ : ${LDSHARED='$(CC)'} AS_IF([test "$GCC" = yes], [ @@ -3356,10 +3354,6 @@ AS_IF([test x"$cross_compiling" = xyes], [ AC_SUBST(XRUBY_RUBYLIBDIR) AC_SUBST(XRUBY_RUBYHDRDIR) PREP='$(arch)-fake.rb' - AS_CASE(["$enable_shared:$EXTSTATIC:$target_os"], [no::darwin*], [ - # darwin target requires miniruby for linking ext bundles - PREP="$PREP"' miniruby$(EXEEXT)' - ]) RUNRUBY_COMMAND='$(MINIRUBY) -I`cd $(srcdir)/lib; pwd`' RUNRUBY='$(RUNRUBY_COMMAND)' XRUBY='$(MINIRUBY)' ``` -- https://bugs.ruby-lang.org/

4 7

[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: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:115197] [Ruby master Misc#19980] Is the Ruby 3.3 ABI frozen?
by mdalessio (Mike Dalessio) 13 Dec '23

13 Dec '23

Issue #19980 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Misc #19980: Is the Ruby 3.3 ABI frozen? https://bugs.ruby-lang.org/issues/19980 * Author: mdalessio (Mike Dalessio) * Status: Open * Priority: Normal ---------------------------------------- I'm a co-maintainer of [rake-compiler-dock](https://github.com/rake-compiler/rake-compiler-dock) which is used to build precompiled native packages for some gems, including nokogiri, sqlite3, grpc, re2, and ruby-magic. In the past, precompiled native gems generally released support for a new version of Ruby days or weeks after Ruby's release (for example, [Nokogiri v1.14.0 released on 2023-01-12](https://nokogiri.org/CHANGELOG.html)) In some cases, the lack of native gem support has slowed user adoption of the new version of Ruby. This year, I'd like to see native gems release Ruby 3.3 support before the final version is released. This will encourage testing of Ruby 3.3 previews and allow users to immediately upgrade to Ruby 3.3 final when it is released. To do that, I would like to cut a release of the rake-compiler-dock gem (and its [build containers](https://github.com/rake-compiler/rake-compiler-dock/pkgs/contai…) that supports Ruby 3.3 as soon as possible (I already have a feature branch mostly working based on 3.3.0_preview1 at https://github.com/rake-compiler/rake-compiler-dock/pull/105) Is the Ruby 3.3 ABI frozen now? If I build a native gem against Ruby 3.3.0_preview2, is there any reason to believe that it wouldn't work with Ruby 3.3 final when it is released? Thank you for any guidance you can provide. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:112119] [Ruby master Bug#19392] Endless method vs and/or
by zverok (Victor Shepelev) 09 Dec '23

09 Dec '23

Issue #19392 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19392: Endless method vs and/or https://bugs.ruby-lang.org/issues/19392 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [Discovered](https://twitter.com/lucianghinda/status/1617783952353406977) by Lucian Ghinda: ```ruby def test = puts("foo") and puts("bar") # prints "bar" immediately test # prints "foo" ``` It seems that it is a parser error, right?.. ```ruby RubyVM::AbstractSyntaxTree.parse('def test = puts("foo") and puts("bar")') # => # (SCOPE@1:0-1:38 # tbl: [] # args: nil # body: # (AND@1:0-1:38 # (DEFN@1:0-1:22 # mid: :test # body: # (SCOPE@1:0-1:22 # tbl: [] # args: # (ARGS@1:0-1:8 pre_num: 0 pre_init: nil opt: nil first_post: nil post_num: 0 post_init: nil rest: nil kw: nil kwrest: nil block: nil) # body: (FCALL@1:11-1:22 :puts (LIST@1:16-1:21 (STR@1:16-1:21 "foo") nil)))) # (FCALL@1:27-1:38 :puts (LIST@1:32-1:37 (STR@1:32-1:37 "bar") nil)))) ``` E.g. it is parsed as ```ruby (def test = puts("foo")) and (puts("bar")) ``` ...which is hardly intentional or have any practical use. The rightly parsed code in this case _can_ have practical use, like ```ruby def write(data) = File.write(@filename, data) == data.size or raise "Something went wrong" ``` -- https://bugs.ruby-lang.org/

12 19

[ruby-core:115430] [Ruby master Bug#20012] Fix keyword splat passing as regular argument
by jeremyevans0 (Jeremy Evans) 08 Dec '23

08 Dec '23

Issue #20012 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20012: Fix keyword splat passing as regular argument https://bugs.ruby-lang.org/issues/20012 * 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 ---------------------------------------- Since Ruby 3.0, Ruby has passed a keyword splat as a regular argument in the case of a call to a Ruby method where the method does not accept keyword arguments, if the method call does not contain an argument splat: ```ruby def self.f(obj) obj end def self.fs(*obj) obj[0] end h = {a: 1} f(**h).equal?(h) # Before: true; After: false fs(**h).equal?(h) # Before: true; After: false a = [] f(*a, **h).equal?(h) # Before and After: false fs(*a, **h).equal?(h) # Before and After: false ``` The fact that the behavior differs when passing an empty argument splat makes it obvious that something is not working the way it is intended. The fact that the hash is copied for C methods also makes it obvious. Ruby 2 always copied the keyword splat hash, and I think that is the expected behavior in Ruby 3. This bug is because of a missed check in setup_parameters_complex. If the keyword splat passed is not mutable, then it points to an existing object and not a new object, and therefore it must be copied. I did not bisect to find the commit that introduced the problem, but this seems likely to be something I introduced during keyword argument separation. I'm surprised that this has not been filed as a bug sooner. Maybe it just rarely comes up in practice, and I only discovered it recently. Possibly, other developers that may have discovered this may have decided against submitting this as an issue, as we have had specs for two years that give the impression that the broken behavior was expected. I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/8970 -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114722] [Ruby master Bug#19877] Non intuitive behavior of syntax only applied to literal value
by tompng (tomoya ishida) 07 Dec '23

07 Dec '23

Issue #19877 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19877: Non intuitive behavior of syntax only applied to literal value https://bugs.ruby-lang.org/issues/19877 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-08T23:08:32Z master b635a66e95) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Non intuitive behavior of syntax only applied to literal value Some ruby syntax is only applied to literal value. ~~~ruby def 1.foo; end # receiver is a literal, it is Syntax Error /(?<a>)/ =~ s # receiver is regexp literal, it will assign to local variable if cond1..cond2; end # range-like syntax appears in condition, it is flipflop ~~~ If it is wrapped with parenthesis, the behavior seems not intuitive for me, and YARP parses it differently. ~~~ruby def (1).foo; end # Syntax Error def ((1;1)).foo; end # Syntax Error def ((;1)).foo; end # Syntax OK def ((1+1;1)).foo; end # Syntax OK def ((%s();1)).foo; end # Syntax Error def ((%w();1)).foo; end # Syntax OK def ("#{42}").foo; end # Syntax Error def (:"#{42}").foo; end # Syntax OK (/(?<a>)/) =~ s # assigns to a (;/(?<a>)/) =~ s # does not assigns (%s();/(?<a>)/) =~ s # assigns to a (%w();/(?<a>)/) =~ s # does not assigns (1; (2; 3; (4; /(?<a>)/))) =~ s # assigns to a (1+1; /(?<a>)/) =~ s # does not assign if ((cond1..cond2)); end # flipflop if (; cond1..cond2); end # range if (1; cond1..cond2); end # flipflop if (%s(); cond1..cond2); end # flipflop if (%w(); cond1..cond2); end # range if (1; (2; (3; 4; cond1..cond2))); end # flipflop if (1+1; cond1..cond2); end # range ~~~ I expect YARP and parse.y parses same. I expect all parenthesis-wrapped result same. I think it is simple and intuitive if parenthesis-wrapped code always behaves different from non-wrapped code because there are more complex variation like this ~~~ruby def (class A; 1; end).foo; end (break; /?<a>/) =~ s class A; /?<a>/; end =~ s ~~~ -- https://bugs.ruby-lang.org/

4 5