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

[ruby-core:119401] [Ruby master Bug#20776] [PRISM] Pattern matching syntax error message
by nobu (Nobuyoshi Nakada) 29 Jul '25

29 Jul '25

Issue #20776 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20776: [PRISM] Pattern matching syntax error message https://bugs.ruby-lang.org/issues/20776 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Syntax error is fine, but is really expecting end-of-input there? ``` $ ruby -v -e '1 => $g' ruby 3.4.0dev (2024-10-01T14:59:58Z master 169a5ee99e) +PRISM [arm64-darwin23] -e:1: warning: possibly useless use of a variable in void context -e: -e:1: syntax errors found (SyntaxError) > 1 | 1 => $g | ^~ unexpected global variable, expecting end-of-input | ^~ expected a pattern expression after `=>` 2 | ``` And the line 2 is **not** in the input. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:120617] [Ruby master Feature#21028] Method for finding why an object isn't Ractor shareable
by tenderlovemaking (Aaron Patterson) 26 Jul '25

26 Jul '25

Issue #21028 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21028: Method for finding why an object isn't Ractor shareable https://bugs.ruby-lang.org/issues/21028 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- `Ractor.shareable?` is easy to use, but if it returns false I would like to be able to figure out what object is causing the data structure to _not_ be Ractor shareable. The context is that I'm trying to make some complex data structures in Rails deeply frozen. If they are deeply frozen they _should_ be Ractor shareable, but `Ractor.shareable?` is returning `false` and it's hard for me to figure out _why_. I would like a method that would either return all unshareable references, or a method that takes a block and unshareable references are yielded to the block. A method like `Ractor.unshareable_references?` or maybe `Ractor.shareable?(obj) { |not_shareable_obj| }` would be very helpful for discovering why an object is not shareable. Thanks! -- https://bugs.ruby-lang.org/

4 6

[ruby-core:120694] [Ruby master Bug#21039] Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks
by Eregon (Benoit Daloze) 24 Jul '25

24 Jul '25

Issue #21039 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21039: Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks https://bugs.ruby-lang.org/issues/21039 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby def make_counter count = 0 nil.instance_exec do [-> { count }, -> { count += 1 }] end end get, increment = make_counter reader = Thread.new { sleep 0.01 loop do p get.call sleep 0.1 end } writer = Thread.new { loop do increment.call sleep 0.1 end } ractor_thread = Thread.new { sleep 1 Ractor.make_shareable(get) } sleep 2 ``` This prints: ``` 1 2 3 4 5 6 7 8 9 10 10 10 10 10 10 10 10 10 10 10 ``` But it should print 1..20, and indeed it does when commenting out the `Ractor.make_shareable(get)`. This shows a given block/Proc instance is concurrently broken by `Ractor.make_shareable`, IOW Ractor is breaking fundamental Ruby semantics of blocks and their captured/outer variables or "environment". It's expected that `Ractor.make_shareable` can `freeze` objects and that may cause some FrozenError, but here it's not a FrozenError, it's wrong values being read. I think what should happen instead is that `Ractor.make_shareable` should create a new Proc and mutate that. However, if the Proc is inside some other object and not just directly the argument, that wouldn't work (like `Ractor.make_shareable([get])`). So I think one fix would to be to only accept Procs for `Ractor.make_shareable(obj, copy: true)`. FWIW that currently doesn't allow Procs, it gives `<internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError)`. I think the only other way, and I think it would be a far better way would be to not support making Procs shareable with `Ractor.make_shareable`. Instead it could be some new method like `isolated { ... }` or `Proc.isolated { ... }` or `Proc.snapshot_outer_variables { ... }` or so, only accepting a literal block (to avoid mutating/breaking an existing block), and that would snapshot outer variables (or require no outer variables like Ractor.new's block, or maybe even do `Ractor.make_shareable(copy: true)` on outer variables) and possibly also set `self` since that's anyway needed. That would make such blocks with different semantics explicit, which would fix the problem of breaking the intention of who wrote that block and whoever read that code, expecting normal Ruby block semantics, which includes seeing updated outer variables. Related: #21033 https://bugs.ruby-lang.org/issues/18243#note-5 Extracted from https://bugs.ruby-lang.org/issues/21033#note-14 -- https://bugs.ruby-lang.org/

5 14

[ruby-core:115422] [Ruby master Bug#20009] Marshal.load raises exception when load dumped class include non-ASCII
by ippachi (Kazuya Hatanaka) 19 Jul '25

19 Jul '25

Issue #20009 has been reported by ippachi (Kazuya Hatanaka). ---------------------------------------- Bug #20009: Marshal.load raises exception when load dumped class include non-ASCII https://bugs.ruby-lang.org/issues/20009 * Author: ippachi (Kazuya Hatanaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Reproduction code ```ruby class Cクラス; end Marshal.load(Marshal.dump(Cクラス)) ``` ## Actual result ``` <internal:marshal>:34:in `load': undefined class/module C\xE3\x82\xAF\xE3\x83\xA9\xE3\x82\xB9 (ArgumentError) from marshal.rb:2:in `<main>' ``` ## Expected result Returns `Cクラス` ## Impacted area An exception is raised in Rails under the following conditions * minitest is used with default settings * Parallel execution with parallelize * test class names contain non-ASCII characters The default parallelization uses DRb, and Marshal is used inside DRb. ## Other After trying various things, I thought I could fix it by making `rb_path_to_class` support strings containing non-ASCII characters, but I couldn't find anything more than that. -- https://bugs.ruby-lang.org/

7 13

[ruby-core:120579] [Ruby master Feature#21020] Sync sig directory for prism of default gem.
by ksss (Yuki Kurihara) 18 Jul '25

18 Jul '25

Issue #21020 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Feature #21020: Sync sig directory for prism of default gem. https://bugs.ruby-lang.org/issues/21020 * Author: ksss (Yuki Kurihara) * Status: Open ---------------------------------------- Currently, the type signatures (RBS) for the default gem is not available. **Prism** is the only default gem with type signatures, but this number is expected to increase in the future. As a first step to resolving this issue, I propose including the `sig` directory of Prism as a default gem in the synchronization process. PR: https://github.com/ruby/ruby/pull/12541 -- https://bugs.ruby-lang.org/

5 5

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 15 Jul '25

15 Jul '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

8 27

[ruby-core:120833] [Ruby master Bug#21099] TestGc#test_gc_stress_at_startup assertion failure
by sanjioh (Fabio Sangiovanni) 14 Jul '25

14 Jul '25

Issue #21099 has been reported by sanjioh (Fabio Sangiovanni). ---------------------------------------- Bug #21099: TestGc#test_gc_stress_at_startup assertion failure https://bugs.ruby-lang.org/issues/21099 * Author: sanjioh (Fabio Sangiovanni) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) +PRISM [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi all, I'm running macOS 15.2, and on my machine the test `TestGc#test_gc_stress_at_startup` results in an assertion failure. These are my current configure flags: ``` ../configure \ --prefix="$SOURCEDIR/ruby_3.4.1" \ --enable-debug-env \ --enable-devel \ cppflags="-DRUBY_DEBUG" \ optflags="-O0 -fno-omit-frame-pointer" ``` make command line for running tests (invoked from the build directory): ``` make test-all TESTS="../test/ruby/test_gc.rb --name=TestGc#test_gc_stress_at_startup" ``` output: ``` Run options: --seed=7555 "--ruby=./miniruby -I../lib -I. -I.ext/common ../tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=../test/.excludes --name=!/memory_leak/ --name=TestGc#test_gc_stress_at_startup # Running tests: [1/1] TestGc#test_gc_stress_at_startup = 3.18 s 1) Failure: TestGc#test_gc_stress_at_startup [/Users/fabio/ruby_xcode/ruby/test/ruby/test_gc.rb:776]: [Bug #15784] pid 16632 killed by SIGABRT (signal 6) | ../gc/default/default.c:1714: Assertion Failed: heap_add_poolpage:page->freelist != NULL | ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) [x86_64-darwin24] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | -- Control frame information ----------------------------------------------- | c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] | | | -- Threading information --------------------------------------------------- | Total ractor count: 0 | Ruby thread count for this ractor: 0 | | -- C level backtrace information ------------------------------------------- | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace+0x1d) [0x10515014d] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:823 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace) (null):0 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_vm_bugreport+0x2c1) [0x105150431] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:1155 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x156) [0x104e41056] /Users/fabio/ruby_xcode/ruby/build/../error.c:1215 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x0) [0x104e40f00] /Users/fabio/ruby_xcode/ruby/build/../error.c:1191 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure) (null):0 | /Users/fabio/ruby_xcode/ruby/build/ruby(heap_add_poolpage+0xa9) [0x104e84ea9] ../gc/default/default.c:1714 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_step+0x204) [0x104e80224] ../gc/default/default.c:3941 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_rest+0x53) [0x104e7fff3] ../gc/default/default.c:3979 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep+0x98) [0x104e7c418] ../gc/default/default.c:4151 | /Users/fabio/ruby_xcode/ruby/build/ruby(gc_start+0x5f9) [0x104e86159] ../gc/default/default.c:6472 | /Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect+0x2c) [0x104e87bbc] ../gc/default/default.c:6351 | /Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect_with_gvl+0xb4) [0x104e8dbc4] ../gc/default/default.c:6753 | /Users/fabio/ruby_xcode/ruby/build/ruby(objspace_malloc_gc_stress+0x8f) [0x104e8daff] ../gc/default/default.c:7996 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_gc_impl_malloc+0x49) [0x104e8d8f9] ../gc/default/default.c:8207 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2_body+0x32) [0x104e76a82] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4699 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2+0x1d) [0x104e76a3d] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4693 | /Users/fabio/ruby_xcode/ruby/build/ruby(pin_array_list_new+0x6f) [0x10511ab3f] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4389 | /Users/fabio/ruby_xcode/ruby/build/ruby(Init_vm_objects+0x1b) [0x10511aa6b] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4446 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_setup+0x46) [0x104e4f0e6] /Users/fabio/ruby_xcode/ruby/build/../eval.c:82 | /Users/fabio/ruby_xcode/ruby/build/ruby(ruby_init+0xd) [0x104e4f3fd] /Users/fabio/ruby_xcode/ruby/build/../eval.c:98 | /Users/fabio/ruby_xcode/ruby/build/ruby(rb_main+0x2b) [0x104d2e6bb] /Users/fabio/ruby_xcode/ruby/build/../main.c:39 | /Users/fabio/ruby_xcode/ruby/build/ruby(main+0x62) [0x104d2e662] /Users/fabio/ruby_xcode/ruby/build/../main.c:65 | | -- Other runtime information ----------------------------------------------- | | * Process memory map: | | 104d2d000-105308000 r-x /Users/fabio/ruby_xcode/ruby/build/ruby | 105308000-105315000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby | 105315000-105317000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby | 105317000-10532c000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby | 10532c000-105500000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby | 105500000-105502000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105502000-105507000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105507000-105508000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105508000-10550c000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 10550c000-10550d000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 10550d000-105516000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105516000-105517000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105517000-105518000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105518000-105521000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105521000-105522000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105522000-105523000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105523000-105524000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105524000-10552b000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105530000-105540000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 105573000-1055d3000 r-x /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055d3000-1055d7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055d7000-1055db000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055db000-1055e7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib | 1055e7000-105c3e000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby | 105c3e000-106295000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby | 600000000000-600020000000 rw- | 7f9643f00000-7f9644000000 rw- | 7f9644000000-7f9644800000 rw- | 7f9644800000-7f9644900000 rw- | 7f9644900000-7f9644901000 rw- | 7f9644a00000-7f9644b00000 rw- | 7ff7b71d3000-7ff7ba9d3000 --- | 7ff7ba9d3000-7ff7bb1d3000 rw- | 7ff800000000-7ff840000000 r-- | 7ff840000000-7ff844b02000 r-- | 7ff844b02000-7ff844b4a000 r-- | 7ff844b4a000-7ff844c00000 rw- | 7ff844c00000-7ff844e00000 rw- | 7ff844e00000-7ff845000000 rw- | 7ff845000000-7ff845200000 rw- | 7ff845200000-7ff845400000 rw- | 7ff845400000-7ff845600000 rw- | 7ff845600000-7ff880000000 r-- | 7ff880000000-7ffd40000000 r-- | 7ffd40000000-7ffd44400000 r-- | 7ffd44400000-7ffd44600000 rw- | 7ffd44600000-7ffd44800000 rw- | 7ffd44800000-7ffd80000000 r-- | 7ffd80000000-7ffffe000000 r-- | 7fffffe00000-7fffffe01000 r-- | 7ffffffad000-7ffffffae000 r-x | [IMPORTANT] | Don't forget to include the Crash Report log file under | DiagnosticReports directory in bug reports. | . 1. [2/3] Assertion for "stderr" | <[]> expected but was | <["../gc/default/default.c:1714: Assertion Failed: heap_add_poolpage:page->freelist != NULL", | "ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) [x86_64-darwin24]", | "", | "-- Crash Report log information --------------------------------------------", | " See Crash Report log file in one of the following locations:", | " * ~/Library/Logs/DiagnosticReports", | " * /Library/Logs/DiagnosticReports", | " for more details.", | "Don't forget to include the above Crash Report log file in bug reports.", | "", | "-- Control frame information -----------------------------------------------", | "c:0001 p:---- s:0003 e:000002 DUMMY [FINISH]", | "", | "", | "-- Threading information ---------------------------------------------------", | "Total ractor count: 0", | "Ruby thread count for this ractor: 0", | "", | "-- C level backtrace information -------------------------------------------", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace+0x1d) [0x10515014d] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:823", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_print_backtrace) (null):0", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_vm_bugreport+0x2c1) [0x105150431] /Users/fabio/ruby_xcode/ruby/build/../vm_dump.c:1155", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x156) [0x104e41056] /Users/fabio/ruby_xcode/ruby/build/../error.c:1215", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure_detail+0x0) [0x104e40f00] /Users/fabio/ruby_xcode/ruby/build/../error.c:1191", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_assert_failure) (null):0", | "/Users/fabio/ruby_xcode/ruby/build/ruby(heap_add_poolpage+0xa9) [0x104e84ea9] ../gc/default/default.c:1714", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_step+0x204) [0x104e80224] ../gc/default/default.c:3941", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep_rest+0x53) [0x104e7fff3] ../gc/default/default.c:3979", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_sweep+0x98) [0x104e7c418] ../gc/default/default.c:4151", | "/Users/fabio/ruby_xcode/ruby/build/ruby(gc_start+0x5f9) [0x104e86159] ../gc/default/default.c:6472", | "/Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect+0x2c) [0x104e87bbc] ../gc/default/default.c:6351", | "/Users/fabio/ruby_xcode/ruby/build/ruby(garbage_collect_with_gvl+0xb4) [0x104e8dbc4] ../gc/default/default.c:6753", | "/Users/fabio/ruby_xcode/ruby/build/ruby(objspace_malloc_gc_stress+0x8f) [0x104e8daff] ../gc/default/default.c:7996", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_gc_impl_malloc+0x49) [0x104e8d8f9] ../gc/default/default.c:8207", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2_body+0x32) [0x104e76a82] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4699", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_xmalloc2+0x1d) [0x104e76a3d] /Users/fabio/ruby_xcode/ruby/build/../gc.c:4693", | "/Users/fabio/ruby_xcode/ruby/build/ruby(pin_array_list_new+0x6f) [0x10511ab3f] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4389", | "/Users/fabio/ruby_xcode/ruby/build/ruby(Init_vm_objects+0x1b) [0x10511aa6b] /Users/fabio/ruby_xcode/ruby/build/../vm.c:4446", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_setup+0x46) [0x104e4f0e6] /Users/fabio/ruby_xcode/ruby/build/../eval.c:82", | "/Users/fabio/ruby_xcode/ruby/build/ruby(ruby_init+0xd) [0x104e4f3fd] /Users/fabio/ruby_xcode/ruby/build/../eval.c:98", | "/Users/fabio/ruby_xcode/ruby/build/ruby(rb_main+0x2b) [0x104d2e6bb] /Users/fabio/ruby_xcode/ruby/build/../main.c:39", | "/Users/fabio/ruby_xcode/ruby/build/ruby(main+0x62) [0x104d2e662] /Users/fabio/ruby_xcode/ruby/build/../main.c:65", | "", | "-- Other runtime information -----------------------------------------------", | "", | "* Process memory map:", | "", | "104d2d000-105308000 r-x /Users/fabio/ruby_xcode/ruby/build/ruby", | "105308000-105315000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby", | "105315000-105317000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby", | "105317000-10532c000 rw- /Users/fabio/ruby_xcode/ruby/build/ruby", | "10532c000-105500000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby", | "105500000-105502000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105502000-105507000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105507000-105508000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105508000-10550c000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "10550c000-10550d000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "10550d000-105516000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105516000-105517000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105517000-105518000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105518000-105521000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105521000-105522000 --- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105522000-105523000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105523000-105524000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105524000-10552b000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105530000-105540000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "105573000-1055d3000 r-x /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055d3000-1055d7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055d7000-1055db000 rw- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055db000-1055e7000 r-- /usr/local/Cellar/gmp/6.3.0/lib/libgmp.10.dylib", | "1055e7000-105c3e000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby", | "105c3e000-106295000 r-- /Users/fabio/ruby_xcode/ruby/build/ruby.dSYM/Contents/Resources/DWARF/ruby", | "600000000000-600020000000 rw-", | "7f9643f00000-7f9644000000 rw-", | "7f9644000000-7f9644800000 rw-", | "7f9644800000-7f9644900000 rw-", | "7f9644900000-7f9644901000 rw-", | "7f9644a00000-7f9644b00000 rw-", | "7ff7b71d3000-7ff7ba9d3000 ---", | "7ff7ba9d3000-7ff7bb1d3000 rw-", | "7ff800000000-7ff840000000 r--", | "7ff840000000-7ff844b02000 r--", | "7ff844b02000-7ff844b4a000 r--", | "7ff844b4a000-7ff844c00000 rw-", | "7ff844c00000-7ff844e00000 rw-", | "7ff844e00000-7ff845000000 rw-", | "7ff845000000-7ff845200000 rw-", | "7ff845200000-7ff845400000 rw-", | "7ff845400000-7ff845600000 rw-", | "7ff845600000-7ff880000000 r--", | "7ff880000000-7ffd40000000 r--", | "7ffd40000000-7ffd44400000 r--", | "7ffd44400000-7ffd44600000 rw-", | "7ffd44600000-7ffd44800000 rw-", | "7ffd44800000-7ffd80000000 r--", | "7ffd80000000-7ffffe000000 r--", | "7fffffe00000-7fffffe01000 r--", | "7ffffffad000-7ffffffae000 r-x", | "[IMPORTANT]", | "Don't forget to include the Crash Report log file under", | "DiagnosticReports directory in bug reports.", | ""]>. 2. [3/3] Assertion for "success?" | Expected #<Process::Status: pid 16632 SIGABRT (signal 6)> to be success?. Finished tests in 3.208725s, 0.3117 tests/s, 1.8699 assertions/s. 1 tests, 6 assertions, 1 failures, 0 errors, 0 skips ruby -v: ruby 3.5.0dev (2025-01-29T15:16:47Z master d3bb42776c) +PRISM [x86_64-darwin24] make: *** [uncommon.mk:965: yes-test-all] Error 1 ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120618] [Ruby master Bug#21029] Prism behavior for `defined? (;x)` differs
by qnighy (Masaki Hara) 14 Jul '25

14 Jul '25

Issue #21029 has been reported by qnighy (Masaki Hara). ---------------------------------------- Bug #21029: Prism behavior for `defined? (;x)` differs https://bugs.ruby-lang.org/issues/21029 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-11T03:21:57Z master 1b3037081e) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism has a different behavior for `(;expr)` when used in `defined?` predicate: ```console % ./miniruby --parser=prism -e "p defined? (;x)" nil % ./miniruby --parser=parse.y -e "p defined? (;x)" "expression" ``` Although not a significant difference, aligning either of them with the other would be better. -- https://bugs.ruby-lang.org/

5 11

[ruby-core:111027] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors
by fxn (Xavier Noria) 14 Jul '25

14 Jul '25

Issue #19154 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #19154: Specify require and autoload guarantees in ractors https://bugs.ruby-lang.org/issues/19154 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given a file `c.rb`: ```ruby class C end ``` the following script: ```ruby r1 = Ractor.new do require './c.rb' end r2 = Ractor.new do require './c.rb' end r1.take r2.take ``` raises: ``` % ruby -v foo.rb ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22] foo.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x000000010fee2928 run> terminated with exception (report_on_exception is true): #<Thread:0x00000001102acfe0 run> terminated with exception (report_on_exception is true): <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:6:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require'<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': : can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' from foo.rb:6:in `block in <main>' <internal:ractor>:698:in `take': thrown by remote Ractor. (Ractor::RemoteError) from foo.rb:9:in `<main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require' from foo.rb:2:in `block in <main>' <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>' ``` Would it be possible to have documentation about their interaction? This is important also to understand autoloading within ractors, since constant references may trigger `require` calls. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 10 Jul '25

10 Jul '25

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

20 73