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

[ruby-core:117003] [Ruby master Bug#20314] Simultaneous Timeout expires may raise an exception after the block
by mame (Yusuke Endoh) 11 Dec '25

11 Dec '25

Issue #20314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20314: Simultaneous Timeout expires may raise an exception after the block https://bugs.ruby-lang.org/issues/20314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Launchable reports `TestTimeout#test_nested_timeout` as a flaky test, and I reproduced it as follows. ```ruby require "timeout" class A < Exception end class B < Exception end begin Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do nil while true end end rescue A, B p $! #=> #<A: execution expired> # Exception B is raised after the above call returns #=> test.rb:16:in `p': execution expired (B) p :end # not reach end ``` This is because the timer thread performs two consecutive `Thread#raise` to the target thread. I have discussed this with @ko1 and have come up with three solutions. ### Solution 1 When multiple nested Timeouts expire simultaneously, raise an exception for the outer-most Timeout and let the inner Timeouts expire without throwing an exception. In the above example, it would only raise A. The problem with this approach is that if you are rescuing A in the inner block, it may never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue A sleep # The exception A is caught. The inner Timeout is already expired, so the code (may) never end. end end end ``` Note that, if A and B did not occur at the same time, it would raise B. This is a race condition. ### Solution 2 When multiple nested Timeouts expire simultaneously, raise an exception for the inner-most Timeout and let the outer Timeouts wait until the inner-most Timeout returns. In the above example, it would raise either A or B, not both. The problem with this approach is that if you are rescuing B in the inner block, it never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue B sleep # The outer Timeout waits for the inner timeout, and the inner Timeout never return. So this code never ends. end end end ``` ### Solution 3 Make thread interrupt queue one length. If the target thread has already been `Thread#raise(A)`, the new `Thread#raise(B)` blocks until the target thread processes A. Since there will be no more simultaneous Thread#raise, there will be no more exceptions after the end of the block. The timeout timer thread should be changed in consideration that `Thread#raise` may block. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124156] [Ruby Bug#21775] Procs of type ifunc can access unshareable values
by etienne 11 Dec '25

11 Dec '25

Issue #21775 has been reported by etienne (Étienne Barrié). ---------------------------------------- Bug #21775: Procs of type ifunc can access unshareable values https://bugs.ruby-lang.org/issues/21775 * Author: etienne (Étienne Barrié) * Status: Open * ruby -v: ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- With this code, we can see that the Ractor is able to access the top-level main object. ``` ruby Ractor.alias_method :value, :take unless Ractor.method_defined?(:value) shareable_proc = Ractor.make_shareable(Hash.new { self }.to_proc) p shareable_proc[0] # => main p Ractor.new(shareable_proc) { |shareable_proc| shareable_proc[0] }.value # => main ``` The proc should not be shareable because its `self` is `main` which is not shareable. It impacts all the versions since Ractors were introduced. `Ractor.shareable_proc` should be able to replace `self` with `nil`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124154] [Ruby Bug#18733] Heavy GC allocations cause performance issue with Ractor
by jhawthorn (John Hawthorn) 11 Dec '25

11 Dec '25

Issue #18733 has been updated by jhawthorn (John Hawthorn). Just to update that though GC is still global more progress has been made. I'm on a new PC, so rerunning the benchmark against the old SHA. ``` ❯ ruby -v ruby 3.5.0dev (2025-07-02T20:01:24Z v4.0.0-preview2~2697 d5f5a56bf2) +PRISM [x86_64-linux] ❯ ruby -W0 test.rb 0.000000 0.001562 28.821554 ( 3.660323) 31.873376 3.184418 35.057794 ( 12.195926) ``` ``` ❯ ruby -v ruby 4.0.0dev (2025-12-11T17:53:18Z master 89e09e4daf) +PRISM [x86_64-linux] ❯ ruby test.rb 0.001531 0.000000 26.558190 ( 3.387530) 31.540110 1.433400 32.973510 ( 8.224187) ``` ---------------------------------------- Bug #18733: Heavy GC allocations cause performance issue with Ractor https://bugs.ruby-lang.org/issues/18733#change-115612 * Author: jakit (Jakit Liang) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Code: ``` require 'benchmark' def fib(n) return n if [0,1].include?(n) fib(n-1) + fib(n-2) end tp = [] puts Benchmark.measure { 8.times do tp << fork { fib(37) } end tp.each { |t| Process.wait(t) } } puts Benchmark.measure { 8.times.map { Ractor.new { fib(37) } }.each{ |r| r.take } } ``` Result: |A |B | |--|--| | fork | 0.000264 0.003439 87.181198 ( 11.211349) | | Ractor | 80.292916 15.062559 95.355475 ( 39.569527) | And I found that here's the problem showing on the ActiveMonitor.app: ![ruby_bug_with_m1](http://jakit.cn/screen_shot_ruby_bug.jpg) As you can see, the process of ruby is always using all Performance Cores on my Apple M1 Mac. But there's no one of the Efficiency Cores was in used by ruby Ractor. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123261] [Ruby Bug#21607] require 'concurrent-ruby' causes segfault with Ruby 3.4.6 on linux/i686
by satadru (Satadru Pramanik) 11 Dec '25

11 Dec '25

Issue #21607 has been reported by satadru (Satadru Pramanik). ---------------------------------------- Bug #21607: require 'concurrent-ruby' causes segfault with Ruby 3.4.6 on linux/i686 https://bugs.ruby-lang.org/issues/21607 * Author: satadru (Satadru Pramanik) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [i686-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As mentioned at https://github.com/ruby/ruby/pull/14532#issuecomment-3288983469 chronos@buppie-i686:2.23 M58 /usr/local/lib/crew/packages (master >|SPARSE)$ ruby -e "require 'concurrent-ruby' ; puts 'success'" Segmentation fault This causes a segfault on i686 only on our Chromebrew/i686 systems. armv7l and x86_64 do not have this issue. This may be linked to the update to prism 1.5.x? Docker reproducer on our i686 ChromeOS Milestone 58 based container image: docker run --init --platform linux/386 --rm --net=host -v $(pwd):/output -h $(hostname)-i686 --tmpfs /tmp --ulimit "nofile=$(ulimit -Sn):$(ulimit -Hn)" -it satmandu/crewbuild:alex-i686.m58 # Note the lack of an issue with 3.4.5 with this command: ruby -e "require 'concurrent-ruby' ; puts 'success'" # In that container, upgrade ruby to 3.4.6: CREW_REPO=https://github.com/chromebrew/chromebrew.git CREW_BRANCH=updater-ruby_3.4.6 crew update \ && yes | crew upgrade # Then run the breaking command: ruby -e "require 'concurrent-ruby' ; puts 'success'" # Note the segfault. -- https://bugs.ruby-lang.org/

8 17

[ruby-core:124152] [Ruby Bug#17878] bootstraptest/test_ractor.rb:224 a random failing test with "The outgoing-port is already closed (Ractor::ClosedError)"
by jhawthorn (John Hawthorn) 11 Dec '25

11 Dec '25

Issue #17878 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed It's likely this was fixed by the introduction of Ractor::Port. "The outgoing-port is already closed" isn't a message that can occur anymore (we no longer have outgoing ports) ---------------------------------------- Bug #17878: bootstraptest/test_ractor.rb:224 a random failing test with "The outgoing-port is already closed (Ractor::ClosedError)" https://bugs.ruby-lang.org/issues/17878#change-115610 * Author: jaruga (Jun Aruga) * Status: Closed * Assignee: ractor * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I was running Travis several times I am trying to revive based on the master commit: `50a534a1526e2b9f4ea41e44b802bd73f9cebbeb`. Then I got the following failure on Travis arm64 Ubuntu focal environment. The failure happened for the first time in around 5 times. Here is the Travis log. https://travis-ci.com/github/junaruga/ruby/jobs/506885939#L2227 ``` $ $SETARCH make -s test -o showflags TESTOPTS="${TESTOPTS=-j33 -q --tty=no}" ... test_ractor.rb ....................Fstderr output is not empty <internal:ractor>:345:in `select': The outgoing-port is already closed (Ractor::ClosedError) from bootstraptest.tmp.rb:12:in `block in test' from bootstraptest.tmp.rb:11:in `times' from bootstraptest.tmp.rb:11:in `test' from bootstraptest.tmp.rb:26:in `block in <main>' from bootstraptest.tmp.rb:25:in `times' from bootstraptest.tmp.rb:25:in `each' from bootstraptest.tmp.rb:25:in `map' from bootstraptest.tmp.rb:25:in `<main>' ``` ``` Fiber count: 10000 (skipping) #1213 test_ractor.rb:224:in `<top (required)>': def test n rs = (1..n).map do |i| Ractor.new(i) do |i| "r#{i}" end end as = [] all_rs = rs.dup n.times{ r, obj = Ractor.select(*rs) as << [r, obj] rs.delete(r) } if as.map{|r, o| r.object_id}.sort == all_rs.map{|r| r.object_id}.sort && as.map{|r, o| o}.sort == (1..n).map{|i| "r#{i}"}.sort 'ok' else 'ng' end end 30.times.map{|i| test i } #=> "" (expected "[\"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\", \"ok\"]") FAIL 1/1488 tests failed make: *** [uncommon.mk:768: yes-btest-ruby] Error 1 The command "$SETARCH make -s test -o showflags TESTOPTS="${TESTOPTS=$JOBS -q --tty=no}"" exited with 2. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124142] [Ruby Feature#21773] Support for setting encoding when a block is passed to `Net::HTTPResponse.read_body`
by rosa (Rosa Gutierrez ) 11 Dec '25

11 Dec '25

Issue #21773 has been reported by rosa (Rosa Gutierrez ). ---------------------------------------- Feature #21773: Support for setting encoding when a block is passed to `Net::HTTPResponse.read_body` https://bugs.ruby-lang.org/issues/21773 * Author: rosa (Rosa Gutierrez ) * Status: Open ---------------------------------------- Hi everyone, This feature request could be considered a follow-up to https://bugs.ruby-lang.org/issues/2567. Opting in to automatic detection of the right encoding for the body when passing a block to `read_body` results in an error as follows: ``` ruby require "net/http" uri = URI.parse("https://rosa.codes") http = Net::HTTP.new(uri.host, uri.port).tap { it.use_ssl = true } req = Net::HTTP::Get.new(uri) http.request(req) do |response| response.body_encoding = true body = +"" response.read_body do |str| body << str end end # => lib/net/http/response.rb:380:in 'Net::HTTPResponse#read_body': undefined method 'force_encoding' for an instance of Net::ReadAdapter (NoMethodError) ``` It's expected this doesn't work because when passing a block, the body is not kept anywhere in the `Net::HTTPResponse` object, each segment read is just passed to the block via the wrapping `Net::ReadAdapter`. In the case I was handling, I required both to read the body using a block and also set the encoding in the final body. I didn't want to duplicate all the code to do the encoding detection, as it's not trivial. I preferred to rely on the `Net::HTTP` implementation of it. I ended up doing something different, along these lines: ```ruby require "net/http" require "active_support" class Body attr_reader :content delegate_missing_to :content def initialize(&block) @block = block @content = +"" end def <<(str) @content << str @block.call(str) if @block end end uri = URI.parse("https://rosa.codes") http = Net::HTTP.new(uri.host, uri.port).tap { it.use_ssl = true } req = Net::HTTP::Get.new(uri) http.request(req) do |response| response.body_encoding = true dest = Body.new response.read_body(dest) end ``` But this got me wondering whether: - The error that happens when calling `force_encoding` on an instance of `Net::ReadAdapter` should be handled more gracefully or in a more informative way for the user. - This could be better supported by `Net::HTTP`. All the pieces are there; there just isn't an easy way to put them together. There's a way to detect the encoding, there's a way to set a body directly in the response, via `Net::HTTPResponse#body=`, but there's no way to trigger the encoding detection and set it in the body besides the first time the body is read. Thanks for the consideration! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124137] [Ruby Feature#8948] Frozen regex
by mame (Yusuke Endoh) 11 Dec '25

11 Dec '25

Issue #8948 has been updated by mame (Yusuke Endoh). Here is the code we found in the dev meeting: https://github.com/ctrochalakis/mongo-ruby-driver/blob/e632eb570d2f42bddc67… ```ruby class LazyRegexp < Regexp ... def initialize(source, **options) @lazy_source = source super(source.to_s, **options) end ``` https://github.com/wallaby-rails/wallaby-rails/blob/e1d2e748887bbbdf024eb24… ```ruby class RegexpOfHolding < Regexp ... def initialize(str, options, extra_options_str) ... super(str, options) @extra_options_str = extra_options_str end end ``` Also, your PR changes the behavior of `Marshal.load` for a Regexp with encoding: ```diff - assert_equal(/u/, Marshal.load("\004\bI/\a\\u\000\006:\016@encoding\"\vEUC-JP")) + assert_raise(FrozenError) { Marshal.load("\004\bI/\a\\u\000\006:\016@encoding\"\vEUC-JP") } ``` This incompatibility should be fixed. Also, as a general rule, please clearly state when a PR includes such known incompatibilities. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115593 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123902] [Ruby Bug#21710] Segfault when reading object_id after it is set inside RUBY_INTERNAL_EVENT_NEWOBJ
by ivoanjo (Ivo Anjo) 11 Dec '25

11 Dec '25

Issue #21710 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #21710: Segfault when reading object_id after it is set inside RUBY_INTERNAL_EVENT_NEWOBJ https://bugs.ruby-lang.org/issues/21710 * Author: ivoanjo (Ivo Anjo) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-24T08:44:28Z master aeb7689e69) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hey 👋. I caught a following segfault when running the [Datadog Ruby Profiler](https://github.com/datadog/dd-trace-rb) test suite on 4.0.0-preview2. The Datadog Ruby Profiler still uses object_ids in `RUBY_INTERNAL_EVENT_NEWOBJ` to simulate weak references. (We know this is deprecated and we plan to move to [`rb_gc_mark_weak`](https://bugs.ruby-lang.org/issues/19783) in the future). I was able to reproduce this bug with both 4.0.0-preview2 as well as a ruby-head build from 2025-11-24. Here's a [very simple reproducer](https://github.com/ivoanjo/lowlevel-toolkit/pull/1): ```c static void on_newobj_event(VALUE tpval, void *data) { VALUE obj = rb_tracearg_object(rb_tracearg_from_tracepoint(tpval)); if (!rb_objspace_internal_object_p(obj)) rb_obj_id(obj); } static VALUE add_object_id(RB_UNUSED_VAR(VALUE _)) { VALUE tp = rb_tracepoint_new(0, RUBY_INTERNAL_EVENT_NEWOBJ, on_newobj_event, NULL); rb_tracepoint_enable(tp); rb_yield(Qnil); rb_tracepoint_disable(tp); return Qnil; } ``` ```ruby puts RUBY_DESCRIPTION require "lowlevel-toolkit" foo = Struct.new(:foo) bar = nil LowlevelToolkit.add_object_id { bar = foo.new(1) } bar.object_id ``` and here's the segfault: ``` examples/add_object_id.rb:8: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.0.0dev (2025-11-24T08:44:28Z master aeb7689e69) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0012 e:000011 l:y b:---- CFUNC :object_id c:0002 p:0044 s:0008 E:002170 l:n b:---- EVAL examples/add_object_id.rb:8 [FINISH] c:0001 p:0000 s:0003 E:001dc0 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- examples/add_object_id.rb:8:in '<main>' examples/add_object_id.rb:8:in 'object_id' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000079c33b33e2cd RBP: 0x00007ffdcee65d10 RSP: 0x00007ffdcee65cd0 RAX: 0x0000000000000000 RBX: 0x000079c33a4ff058 RCX: 0x000079c339000000 RDX: 0x0000000000000000 RDI: 0x0000000000000000 RSI: 0x00000000000fe000 R8: 0x000079c33b35c078 R9: 0x000079c31f2814d0 R10: 0x000058e4893a6ee0 R11: 0xb84a1fbe2b4aab11 R12: 0x0000000000000002 R13: 0x0000000000000000 R14: 0x000058e489384b60 R15: 0x000079c33a5fefa0 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_print_backtrace+0x24) [0x79c33b392149] .rvm/src/ruby-head/vm_dump.c:1105 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_vm_bugreport+0x33f) [0x79c33b39291b] .rvm/src/ruby-head/vm_dump.c:1450 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_bug_for_fatal_signal+0x147) [0x79c33b13a3e2] .rvm/rubies/ruby-head/lib/libruby.so.4.0(sigsegv+0x84) [0x79c33b2bea4d] .rvm/src/ruby-head/signal.c:948 .rvm/rubies/ruby-head/lib/libruby.so.4.0(sigill) (null):0 /lib/x86_64-linux-gnu/libc.so.6(0x79c33ac45330) [0x79c33ac45330] .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_obj_field_get+0x105) [0x79c33b33e2cd] .rvm/src/ruby-head/variable.c:1412 .rvm/rubies/ruby-head/lib/libruby.so.4.0(object_id_get+0x4e) [0x79c33b16ed28] .rvm/src/ruby-head/gc.c:1875 .rvm/rubies/ruby-head/lib/libruby.so.4.0(object_id0+0x46) [0x79c33b16ed78] .rvm/src/ruby-head/gc.c:1895 .rvm/rubies/ruby-head/lib/libruby.so.4.0(object_id+0xb1) [0x79c33b16ee93] .rvm/src/ruby-head/gc.c:1936 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_find_object_id+0x43) [0x79c33b16f6ea] .rvm/src/ruby-head/gc.c:2179 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_obj_id+0x2e) [0x79c33b16f75a] .rvm/src/ruby-head/gc.c:2234 .rvm/rubies/ruby-head/lib/libruby.so.4.0(ractor_safe_call_cfunc_0+0x30) [0x79c33b35c0a8] .rvm/src/ruby-head/vm_insnhelper.c:3718 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc_with_frame_+0x221) [0x79c33b35ccb1] .rvm/src/ruby-head/vm_insnhelper.c:3902 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc_with_frame+0x76) [0x79c33b35cf26] .rvm/src/ruby-head/vm_insnhelper.c:3948 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc_other+0x12b) [0x79c33b35d053] .rvm/src/ruby-head/vm_insnhelper.c:3974 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_cfunc+0x147) [0x79c33b35d49a] .rvm/src/ruby-head/vm_insnhelper.c:4056 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_method_each_type+0x180) [0x79c33b360161] .rvm/src/ruby-head/vm_insnhelper.c:4888 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_method+0xa1) [0x79c33b360c1d] .rvm/src/ruby-head/vm_insnhelper.c:5014 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_call_general+0x2f) [0x79c33b360e1f] .rvm/src/ruby-head/vm_insnhelper.c:5058 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_sendish+0x1d3) [0x79c33b363689] .rvm/src/ruby-head/vm_insnhelper.c:6124 .rvm/rubies/ruby-head/lib/libruby.so.4.0(vm_exec_core+0x3b1d) [0x79c33b36b42c] .rvm/src/ruby-head/insns.def:903 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_vm_exec+0x140) [0x79c33b384d94] .rvm/src/ruby-head/vm.c:2784 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_iseq_eval_main+0x3d) [0x79c33b385be2] .rvm/src/ruby-head/vm.c:3050 .rvm/rubies/ruby-head/lib/libruby.so.4.0(rb_ec_exec_node+0x128) [0x79c33b145eb4] .rvm/src/ruby-head/eval.c:283 .rvm/rubies/ruby-head/lib/libruby.so.4.0(ruby_run_node+0x8a) [0x79c33b146025] .rvm/src/ruby-head/eval.c:321 .rvm/rubies/ruby-head/bin/ruby(rb_main+0x4c) [0x58e47500e51e] ./main.c:42 .rvm/rubies/ruby-head/bin/ruby(main+0x62) [0x58e47500e596] ./main.c:62 ``` Let me know if I can provide any more info! -- https://bugs.ruby-lang.org/

6 24

[ruby-core:123827] [Ruby Misc#21690] Inconsistent `rb_popcount64()` definition
by daniel.domjan 11 Dec '25

11 Dec '25

Issue #21690 has been reported by daniel.domjan (Dániel Domján). ---------------------------------------- Misc #21690: Inconsistent `rb_popcount64()` definition https://bugs.ruby-lang.org/issues/21690 * Author: daniel.domjan (Dániel Domján) * Status: Open ---------------------------------------- The `rb_popcount64()` function is defined both in `internal/bits.h` and `parser_bits.h`, but the definition of these functions is different on the `#else` branch. ```c // internal/bits.h static inline unsigned int rb_popcount64(uint64_t x) { ... #else x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555); x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333); x = (x & 0x0707070707070707) + (x >> 4 & 0x0707070707070707); x = (x & 0x000f000f000f000f) + (x >> 8 & 0x000f000f000f000f); x = (x & 0x0000001f0000001f) + (x >>16 & 0x0000001f0000001f); x = (x & 0x000000000000003f) + (x >>32 & 0x000000000000003f); return (unsigned int)x; #endif } ``` ```c // parser_bits.h static inline unsigned int rb_popcount64(uint64_t x) { ... #else x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555); x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333); x = (x & 0x0707070707070707) + (x >> 4 & 0x0707070707070707); x = (x & 0x001f001f001f001f) + (x >> 8 & 0x001f001f001f001f); x = (x & 0x0000003f0000003f) + (x >>16 & 0x0000003f0000003f); x = (x & 0x000000000000007f) + (x >>32 & 0x000000000000007f); return (unsigned int)x; #endif } ``` ```diff x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555); x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333); x = (x & 0x0707070707070707) + (x >> 4 & 0x0707070707070707); - x = (x & 0x000f000f000f000f) + (x >> 8 & 0x000f000f000f000f); + x = (x & 0x001f001f001f001f) + (x >> 8 & 0x001f001f001f001f); - x = (x & 0x0000001f0000001f) + (x >>16 & 0x0000001f0000001f); + x = (x & 0x0000003f0000003f) + (x >>16 & 0x0000003f0000003f); - x = (x & 0x000000000000003f) + (x >>32 & 0x000000000000003f); + x = (x & 0x000000000000007f) + (x >>32 & 0x000000000000007f); ``` IIUC, this is a modified [hamming weight](https://en.wikipedia.org/wiki/Hamming_weight) based on [this SO answer](https://stackoverflow.com/a/73300535), so both implementations give the same result, but it's a bit confusing at first look, so I flagged it as `Misc` instead of `Bug`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123914] [Ruby Bug#21712] Prism and parse.y inconsistency in command call with block and `.()`
by tompng (tomoya ishida) 11 Dec '25

11 Dec '25

Issue #21712 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21712: Prism and parse.y inconsistency in command call with block and `.()` https://bugs.ruby-lang.org/issues/21712 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `a b do end.()` `a b do end&.()` are parsed differently. Prism: parse success, parse.y: SyntaxError I personally like Prism's behavior: `.()` and `&.()` are accepted where `.f()` and `&.f()` are accepted. -- https://bugs.ruby-lang.org/

3 3