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

[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

[ruby-core:124131] [Ruby Feature#8948] Frozen regex
by matz (Yukihiro Matsumoto) 11 Dec '25

11 Dec '25

Issue #8948 has been updated by matz (Yukihiro Matsumoto). We found some gems inherited from Regexp and used instance variables on instances, so they would be broken if all Regexp objects become frozen. I think it's unacceptable for Ruby 4.0. Frankly, I don't think freezing the Regexp objects is worth the effort/trouble. Matz. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115583 * 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:123063] [Ruby Feature#21552] allow String.strip and similar to take a parameter similar to String.delete
by MSP-Greg (Greg L) 11 Dec '25

11 Dec '25

Issue #21552 has been reported by MSP-Greg (Greg L). ---------------------------------------- Feature #21552: allow String.strip and similar to take a parameter similar to String.delete https://bugs.ruby-lang.org/issues/21552 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Regrading `String.strip` (and `lstrip`, `rstrip`, and `!` versions) Some text data representations differentiate between what one might call vertical and horizontal white space, and the 'strip' methods currently strip both. It would be helpful if they had an optional parameter similar to `String.delete` with a one multi-character selector, so one could do: ```ruby t = str.strip " \t" ``` One can use a regex for this, but this much simpler. -- https://bugs.ruby-lang.org/

7 11

[ruby-core:124117] [Ruby Bug#15479] Array#reject! modifies literal Array
by sapry1586＠gmail.com (mohamed sapry) 10 Dec '25

10 Dec '25

Issue #15479 has been updated by sapry1586(a)gmail.com (mohamed sapry). Yas ---------------------------------------- Bug #15479: Array#reject! modifies literal Array https://bugs.ruby-lang.org/issues/15479#change-115568 * Author: Eregon (Benoit Daloze) * Status: Closed * Assignee: tenderlovemaking (Aaron Patterson) * ruby -v: ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux] * Backport: 2.4: DONE, 2.5: DONE, 2.6: DONE ---------------------------------------- This was found by running ruby/spec with -R2 (such as mspec -R2 -fs core/array/reject_spec.rb). TravisCI log on https://travis-ci.org/ruby/spec/jobs/473175799#L539 Here is a simple reproducer. MRI seems to modify the Array literal permanently: ```ruby 3.times do a = [1, 2, 3, 4] puts "initial: #{a}" begin a.reject! do |x| case x when 2 then true when 3 then raise StandardError, 'Oops' else false end end rescue StandardError end puts "after: #{a}" end ``` prints ``` initial: [1, 2, 3, 4] after: [1, 3, 4] initial: [1, 3, 4, 4] after: [1, 3, 4, 4] initial: [1, 3, 4, 4] after: [1, 3, 4, 4] ``` 2.5.3 behaves fine, but trunk is also affected. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124103] [Ruby Bug#21771] pg-1.6.2 testsuite segfaults in ruby4.0.0dev
by mtasaka (Mamoru TASAKA) 10 Dec '25

10 Dec '25

Issue #21771 has been reported by mtasaka (Mamoru TASAKA). ---------------------------------------- Bug #21771: pg-1.6.2 testsuite segfaults in ruby4.0.0dev https://bugs.ruby-lang.org/issues/21771 * Author: mtasaka (Mamoru TASAKA) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-09 master edca81a1bb) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Looks like pg-1.6.2 https://github.com/ged/ruby-pg/tree/c75ed8da19c356b52d83da2627295760780d3d36 testsuite began to segfault, especially the following ``` #!/bin/bash export PGPORT=54321 export RUBY_PG_TEST_DIR=/builddir/build/BUILD/tmp export RUBYLIB=/builddir/build/BUILD/rubygem-pg-1.6.2-build/pg-1.6.2/usr/share/gems/gems/pg-1.6.2/lib:/builddir/build/BUILD/rubygem-pg-1.6.2-build/pg-1.6.2/usr/lib64/gems/ruby/pg-1.6.2 # The above path should be replaced properly rm -rf $RUBY_PG_TEST_DIR exec ruby -S --verbose \ -r ./spec/helpers \ rspec -f d \ spec/pg/connection_spec.rb -E '' \ --seed 1 ``` segfaults like below (will write later) It seems that segfaults began to happen between commit:706d80830b9f0a5a2eac66251d1417abb2ff143c (no problem) and commit:d7e55f84f2bd62d302b29513d4c4dc8ae9aef96f (segfaults) Tried with commit:edca81a1bb72a9dc54a37766d2c80790dec13884 it still segfaults. Note that ruby-pg *compiled* with commit:706d80830b9f0a5a2eac66251d1417abb2ff143 does *not* segfault with ruby commit:edca81a1bb72a9dc54a37766d2c80790dec13884 , so I suspect that there is something wrong with "inlined" function or so. -- https://bugs.ruby-lang.org/

3 8

[ruby-core:124071] [Ruby Misc#21770] Stop bumping RUBY_PATCHLEVEL in released versions
by k0kubun (Takashi Kokubun) 09 Dec '25

09 Dec '25

Issue #21770 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21770: Stop bumping RUBY_PATCHLEVEL in released versions https://bugs.ruby-lang.org/issues/21770 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Proposal * Stop bumping `RUBY_PATCHLEVEL` from `0` in Ruby 4.0.0+ ## Motivation * As a stable branch maintainer, I find it frustrating that reverting a commit made by `tool/merger.rb` often causes a conflict on `#define RUBY_PATCHLEVEL`. ## Background * From Ruby 2.1.0, we stopped doing multiple patch-level releases for a single version, e.g. [2.0.0-p647](https://www.ruby-lang.org/en/news/2015/08/18/ruby-2-0-0-p647-re… and [2.0.0-p648](https://www.ruby-lang.org/en/news/2015/12/16/ruby-2-0-0-p648-re… for Ruby 2.0.0. * From Ruby 3.2.0, we stopped showing patch levels on `RUBY_DESCRIPTION` [Feature #18513]. We thought "patch levels no longer serves us very well". * Today, we also backport patches using pull requests on GitHub. We often don't bump `RUBY_PATCHLEVEL` there because it's easier to use `git cherry-pick` instead of `tool/merger.rb`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123951] [Ruby Bug#21719] Thread deadlock with explicit require of a base clase in Linux Ruby 3.4
by jcuello＠fu.do (Juan Manuel Cuello) 09 Dec '25

09 Dec '25

Issue #21719 has been reported by jcuello(a)fu.do (Juan Manuel Cuello). ---------------------------------------- Bug #21719: Thread deadlock with explicit require of a base clase in Linux Ruby 3.4 https://bugs.ruby-lang.org/issues/21719 * Author: jcuello(a)fu.do (Juan Manuel Cuello) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I originally [reported the issue](https://github.com/fxn/zeitwerk/issues/321) in Zeitwerk, but we then figured out that it seems to be related to Ruby. Basically, I'm having a threads deadlock when using requires with autoloadable classes: ```ruby # jobs/base.rb # module Jobs class Base end end # jobs/a.rb # require './jobs/base' module Jobs class A < Base def perform puts self.class.name end end end # jobs/b.rb # module Jobs class B < Base def perform puts self.class.name end end end # start.rb # module Jobs autoload :Base, './jobs/base' autoload :A, './jobs/a' autoload :B, './jobs/b' end a = Thread.new { Jobs::A.new.perform } b = Thread.new { Jobs::B.new.perform } a.join b.join ``` ``` ruby --version && ruby start.rb ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] start.rb:12:in 'Thread#join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x00005ca30dfbc500 main thread:0x00005ca30dd30330 * #<Thread:0x000076b1a7d6a658 sleep_forever> rb_thread_t:0x00005ca30dd30330 native:0x000076b1a81b87c0 int:0 * #<Thread:0x000076b1a7d2e928 start.rb:9 sleep_forever> rb_thread_t:0x00005ca30dfbc500 native:0x000076b18c74d6c0 int:0 depended by: tb_thread_id:0x00005ca30dd30330 * #<Thread:0x000076b1a7d2e3b0 start.rb:10 sleep_forever> rb_thread_t:0x00005ca30dfb0fd0 native:0x000076b18c54b6c0 int:0 mutex:0x00005ca30dfe2b60 cond:1 from start.rb:12:in '<main>' ``` Note the require './jobs/base' in `jobs/a.rb`. If I remove it, everything works. The same happens if I add the same explicit require in `jobs/b.rb`. It seems to have been fixed in ruby 3.4 in commit:ea2af5782df63266577ba08a4ef4c30b6d63e564, but not apparent in Linux (which is my case) until commit:6fbc32b5d0da31535cccc0eca1853273313a0b52 I'm not familiar with the ruby codebase, so It's not clear to me why the change to prism fixed the threads issue and why it didn't have impact in Linux until the other fix, but bisecting the source code and running each revision against the code above, that is what I came to. I can create a PR to backport the Linux fix to `ruby_3_4` branch, as in `master` everything is working as expected. -- https://bugs.ruby-lang.org/

2 1