April 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125238] [Ruby Bug#21993] `rb_gc_update_tbl_refs` is incorrectly documented as the dcompact pair for `rb_mark_tbl_no_pin`, and is unsafe for `st_table`s with non-VALUE keys
by ivoanjo (Ivo Anjo) 17 Apr '26

17 Apr '26

Issue #21993 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #21993: `rb_gc_update_tbl_refs` is incorrectly documented as the dcompact pair for `rb_mark_tbl_no_pin`, and is unsafe for `st_table`s with non-VALUE keys https://bugs.ruby-lang.org/issues/21993 * Author: ivoanjo (Ivo Anjo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hey! I work for Datadog on the [Ruby profiler](https://github.com/datadog/dd-trace-rb) and I've been exploring the TypedData GC API to understand the correct patterns for writing compaction-aware extensions. While reading through the API, I noticed a mismatch between the documented pairing of `rb_mark_tbl_no_pin` + `rb_gc_update_tbl_refs` and what the implementation actually does that seems like it can cause crashes and even corruption for extensions. ### The problem The public header documents `rb_gc_update_tbl_refs` as the `dcompact` counterpart for `rb_mark_tbl_no_pin`: ``` * Updates references inside of tables. After you marked values using * rb_mark_tbl_no_pin(), the objects inside of the table could of course be * moved. This function is to fixup those references. ``` However, `rb_mark_tbl_no_pin`'s implementation only marks **values**, not keys: ```c // gc.c / gc/gc.h static int gc_mark_tbl_no_pin_i(st_data_t key, st_data_t value, st_data_t data) { rb_gc_mark_movable((VALUE)value); // key is never touched return ST_CONTINUE; } ``` Thus, tables used with `rb_mark_tbl_no_pin` can have non-VALUE keys (e.g. `ID`s, raw integers, C pointers, etc). The problem is that `rb_gc_update_tbl_refs` (via `gc_update_table_refs`) calls `rb_gc_location` on **both** keys and values: ```c static int hash_foreach_replace(st_data_t key, st_data_t value, ...) { if (rb_gc_location((VALUE)key) != (VALUE)key) // <- called on key return ST_REPLACE; if (rb_gc_location((VALUE)value) != (VALUE)value) return ST_REPLACE; ... } ``` Calling `rb_gc_location` on something that's not a `VALUE` and even sometimes replacing it is probably going to cause crashes and heap corruption. ### Suggested fixes I can think of a few ways to address this: **a) Deprecate `rb_gc_update_tbl_refs`** Maybe just deprecate it? I'm not even sure if this gets used very often. **b) Introduce `rb_mark_hash_no_pin`** The `mark_keyvalue` iterator already exists internally and is used by `mark_hash()` for Ruby's own `Hash` objects. Exposing a public `rb_mark_hash_no_pin` would give `rb_gc_update_tbl_refs` a safe, correct `dmark` counterpart for tables where both keys and values are Ruby objects. **c) Fix the docs and document the precondition for `rb_gc_update_tbl_refs`** Update the docs to make explicit that `rb_gc_update_tbl_refs` assumes a `VALUE => VALUE` table, and that all keys **must have been marked** (e.g. via `rb_mark_set` or a manual iteration with `rb_gc_mark_movable`) in addition to calling `rb_mark_tbl_no_pin` for the values. Weird and ugly, but correct? --- Happy to help with a patch if useful. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:125284] [Ruby Misc#22006] Usage of deprecated input in gem sync workflows
by Earlopain (Earlopain _) 17 Apr '26

17 Apr '26

Issue #22006 has been reported by Earlopain (Earlopain _). ---------------------------------------- Misc #22006: Usage of deprecated input in gem sync workflows https://bugs.ruby-lang.org/issues/22006 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- `create-github-app-token` deprecated `app-id` in favor of `client-id` in https://github.com/actions/create-github-app-token/releases/tag/v3.1.0. Since it will probably be removed in the next major version, all workflow files need to be updated eventually. I also noticed that `convictional/trigger-workflow-and-wait` has been archived (https://github.com/convictional/trigger-workflow-and-wait) This shouldn't matter much, it is docker-based and should continue to work for a long time unless github does some API change. But this made me think that perhaps this mechanism should be a composite action or something similar? Then you don't need to update it in so many places (currently 47) when something changes. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125280] [Ruby Misc#22005] Missing information about CVE on cve.org
by vo.x (Vit Ondruch) 17 Apr '26

17 Apr '26

Issue #22005 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Misc #22005: Missing information about CVE on cve.org https://bugs.ruby-lang.org/issues/22005 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- The CVE-2026-27820 was fixed and disclosed more than one month ago: https://www.ruby-lang.org/en/news/2026/03/05/buffer-overflow-zlib-cve-2026-… However, there is still no public information on https://www.cve.org/CVERecord?id=CVE-2026-27820 . Could this be fixed please? BTW the same situation was for CVE-2025-61594, where the information was not there for months. This points to a gap in a security release process. Could the process be improved so the information is disclosed in timely manner? -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124955] [Ruby Misc#21948] benchmark gem maintainer
by Eregon (Benoit Daloze) 17 Apr '26

17 Apr '26

Issue #21948 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21948: benchmark gem maintainer https://bugs.ruby-lang.org/issues/21948 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to propose myself as maintainer of [benchmark](https://github.com/ruby/benchmark). I always had an interest about the `benchmark` stdlib and did significant contributions to it, notably [979ec8d](https://github.com/ruby/ruby/commit/979ec8df5daf6db314b2f17e53b53d…. @matz approved it [here](https://github.com/ruby/ruby/pull/15424#issuecomment-3640875676), so this issue is mostly for awareness. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125267] [Ruby Bug#21999] Sometimes getting segfault and sometimes getting a "Floating point exception" when running some ractor code involving BigDecimal
by miles-georgi (Miles Georgi) 16 Apr '26

16 Apr '26

Issue #21999 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #21999: Sometimes getting segfault and sometimes getting a "Floating point exception" when running some ractor code involving BigDecimal https://bugs.ruby-lang.org/issues/21999 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: 4.0.2 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hey hey! I don't know if this might be a duplicate of https://bugs.ruby-lang.org/issues/21992 as the code involves two subclasses of BasicObject that have #initialize methods defined. Apologies if a dup of that! I'm not sure how best to run this against the current tip of ruby but am happy to try that if somebody can point me to how to do it. When running the script here: https://github.com/ractor-shack/ractorize/blob/main/example_scripts/product… I sometimes see a segfault and sometimes I get a "Floating point exception. This does use "bigdecimal" so not sure if the bug might be there. To reproduce, you could clone that repo, go into the example-scripts directory, bundle install, and ./product-benchmark-segfault You might have to run it a few times to see the various bad outcomes. Using 4.0.2 on a debian trixie machine with ruby installed via rbenv. I'll attach some output text. segfault2.txt happens sometimes and has tons of info. This also happens if using path: ".." to point it at the local files instead of the installed gem. I do know C and could attempt to help with this sort of thing. Though, somebody would likely have to be interested in pairing with me to help me ramp up on how to debug a project like MRI. Cheers! ---Files-------------------------------- corrupted_top_size_plus_floating_point_exception.txt (1.28 KB) floating_point_exception.txt (851 Bytes) lucky_successful_run.txt (851 Bytes) segfault1.txt (3.1 KB) segfault2.txt (48.1 KB) product-benchmark-segfault (1.23 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125274] [Ruby Bug#22002] argument stack underflow (-1)
by anonymous128 (Anonymous 128) 15 Apr '26

15 Apr '26

Issue #22002 has been reported by anonymous128 (Anonymous 128). ---------------------------------------- Bug #22002: argument stack underflow (-1) https://bugs.ruby-lang.org/issues/22002 * Author: anonymous128 (Anonymous 128) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following lines of code: ```ruby sleep(0.1) until defined?(@variable) @variable ``` produce this error: ``` home@My-Air testing % bundle exec ruby test.rb -- raw disasm-------- trace: 1 0000 jump <L000> ( 1) <L004> [sp: 0, unremovable: 1, refcnt: 1] 0002 putnil ( 1) <L005> [sp: 1, unremovable: 0, refcnt: 1] 0003 pop ( 1) 0004 jump <L000> ( 1) <L001> [sp: 0, unremovable: 1, refcnt: 5] 0006 putself ( 1) 0007 putobject 0.1 ( 1) 0009 opt_send_without_block <calldata:sleep, 1> ( 1) 0011 pop ( 1) <L000> [sp: 0, unremovable: 0, refcnt: 2] <L012> [sp: 0, unremovable: 0, refcnt: 0] * 0012 branchunless <L001> ( 1) adjust: [label: 4] 0014 putnil ( 1) <L002> [sp: -1, unremovable: 0, refcnt: 4] 0015 pop ( 1) trace: 1 0016 getinstancevariable :@variable, <ivc:0> ( 3) 0019 leave ( 3) --------------------- test.rb:1: argument stack underflow (-1) test.rb: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125269] [Ruby Misc#22000] Requesting to be a co-maintainer of ostruct
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #22000 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #22000: Requesting to be a co-maintainer of ostruct https://bugs.ruby-lang.org/issues/22000 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to become a co-maintainer of the `ostruct` gem (OpenStruct class). I know currently @marcandre is the maintainer of `ostruct` but he seems less active recently (e.g. [open PRs](https://github.com/ruby/ostruct/pulls)) and I would like to become co-maintainer. My particular interest in `ostruct` is that I would like to fix the performance, the current implementation calls `define_singleton_method` for every `ostruct.foo` which is extremely inefficient for all Ruby implementations and all JITs. This has led to basically deprecating `OpenStruct` in its documentation and in some RuboCop rules. However a much faster and simpler implementation would be to rely on `method_missing` which [I have explored in the past](https://github.com/ruby/ostruct/issues/51). This speeds up reading OpenStruct attributes by 6.6x to 2096x. There are compatibility concern so this requires evaluating carefully what OpenStruct subclasses do and might require bumping the major version. I would love to get @marcandre 's opinion on this request but I'm not sure when he will see this. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125234] [Ruby Bug#21990] [ruby-talk:444791] Regression: Ruby 4.0 constantly crashing
by zenspider (Ryan Davis) 14 Apr '26

14 Apr '26

Issue #21990 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21990: [ruby-talk:444791] Regression: Ruby 4.0 constantly crashing https://bugs.ruby-lang.org/issues/21990 * Author: zenspider (Ryan Davis) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- (Filed for a user on ruby-talk who can't get registered here for some reason) After upgrade to ruby 4.0, all our Rails applications are continuously crashing on different nodes at different locations. All the applications were running flawlessly for about a year with 4.0.0.p1 and 4.0.0.p2. Reverting to 4.0.0.p2 solves the issue. The behaviour is the same with 4.0.0 and 4.0.1, where 4.0.1 has the additional issue that the value of ulimit "unlimited" has been reduced below "EFBIG", so no coredumps can be written ("too big"). Bug reporting is not possible: After registering an account on https://bugs.ruby-lang.org/, one is requested to follow the instructions in an e-mail, but such e-mail is never sent; not even after repeatedly requesting it. Versions tried: 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [amd64-freebsd14] 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [amd64-freebsd14] FreeBSD-PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294359 Stuff reported in the logfile (example): ``` Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156: [BUG] Segmentation fault at 0x0000000000000000 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [amd64-freebsd14] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Control frame information ----------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0017 p:---- s:0112 e:000111 l:y b:---- CFUNC :<=> Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0016 p:0021 s:0107 e:000106 l:y b:0001 METHOD /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156 [FINISH] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0015 p:---- s:0102 e:000101 l:y b:---- CFUNC :< Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0014 p:0150 s:0097 e:000096 l:y b:0001 METHOD /ext/rapp/fin_prod/releases/20260408164852/app/jobs/quote_fetch_job.rb:28 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0013 p:0053 s:0084 e:000083 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/job_methods.rb:51 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0012 p:0003 s:0073 e:000072 l:y b:0001 METHOD <internal:kernel>:91 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0011 p:0007 s:0069 e:000068 l:n b:---- BLOCK /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0010 p:0002 s:0066 e:000065 l:n b:---- BLOCK (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0009 p:0027 s:0063 e:000062 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:41 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0008 p:0011 s:0053 e:000052 l:n b:---- BLOCK /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:37 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0007 p:0002 s:0050 e:000049 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/active_record/connection.rb:33 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0006 p:0021 s:0045 e:000044 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:36 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0005 p:0024 s:0035 e:000034 l:y b:0001 METHOD (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0004 p:0050 s:0029 e:000028 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0003 p:0068 s:0012 e:000011 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:76 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0002 p:0026 s:0006 e:000005 l:n b:---- BLOCK /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:46 [FINISH] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0001 p:---- s:0003 e:000002 l:y b:---- DUMMY [FINISH] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Ruby level backtrace information ---------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:46:in 'block in initialize' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:76:in 'work_loop' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103:in 'work_job' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11:in 'run_job_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:36:in 'invoke_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/active_record/connection.rb:33:in 'call' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:37:in 'block in invoke_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:41:in 'invoke_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11:in 'block in run_job_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103:in 'block in work_job' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: <internal:kernel>:91:in 'tap' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/job_methods.rb:51:in '_run' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/rapp/fin_prod/releases/20260408164852/app/jobs/quote_fetch_job.rb:28:in 'run' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/rapp/fin_prod/releases/20260408164852/app/jobs/quote_fetch_job.rb:28:in '<' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156:in 'compare_with_coercion' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156:in '<=>' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Threading information --------------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Total ractor count: 1 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Ruby thread count for this ractor: 6 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- C level backtrace information ------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_profile_frame_full_label+0x233e) [0x822ec5e2e] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_bug_reporter_add) [0x822cc5b00] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(ruby_sig_finalize) [0x822e09934] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /lib/libthr.so.3(pthread_sigmask+0x556) [0x8294dba16] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /lib/libthr.so.3(pthread_signals_unblock_np) [0x8294daf0a] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: [0x821b682d3] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_gc_adjust_memory_usage) [0x822cf7e5e] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_gc_writebarrier+0xdd) [0x822ce66fd] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/date-3.5.1/lib/date_core.so(Init_date_core+0x145) [0x830904b65] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/date-3.5.1/lib/date_core.so(Init_date_core+0xa5) [0x8308f5655] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(ruby_free_at_exit_p) [0x822eb5106] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e97827] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e90b08] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_check_funcall) [0x822ea0571] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_scan_args_kw) [0x822c33448] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(ruby_free_at_exit_p) [0x822eb5106] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e97827] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e90b9b] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_proc_ractor_make_shareable) [0x822ea6e94] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_proc_ractor_make_shareable) [0x822ea62fa] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_internal_thread_specific_set) [0x822e607ec] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_internal_thread_specific_set) [0x822e5ff39] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_internal_thread_specific_set) [0x822e5fa01] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /lib/libthr.so.3(pthread_create) [0x8294d1d68] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Other runtime information ----------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: * Loaded script: /ext/gems/4.0/bin/que Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: * Ruby Box: disabled Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: * Loaded features: [etc.etc.] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 14 Apr '26

14 Apr '26

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/

23 82

[ruby-core:125143] [Ruby Misc#21968] The pathname gem needs a new release
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #21968 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21968: The pathname gem needs a new release https://bugs.ruby-lang.org/issues/21968 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- The current pathname gem release (0.4.0) has several issues: ### Many warnings on Ruby 4.0 It emits many constant & method redefinition warnings. This happens notably when an application has `pathname` as a dependency (direct or transitive) in the Gemfile. This is with the default `$VERBOSE`: ``` $ gem i pathname $ ruby -e 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here ``` And 53 warnings with `-w`: ``` $ ruby -we 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:50: warning: method redefined; discarding old chop_basename <internal:pathname_builtin>:359: warning: previous definition of chop_basename was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:61: warning: method redefined; discarding old split_names <internal:pathname_builtin>:370: warning: previous definition of split_names was here ... ``` See https://github.com/ruby/pathname/issues/66 ### The gem fails to install on JRuby See https://github.com/ruby/pathname/issues/94#issuecomment-4016566593 ### The gem crashes on TruffleRuby It causes errors like `pathname.so: undefined symbol: rb_block_call_kw`. See https://github.com/ruby/pathname/issues/94#issue-4038536603 ### Release request These 3 issues are fixed on ruby/pathname master by https://github.com/ruby/pathname/pull/56 and https://github.com/ruby/pathname/pull/57, but no release including those fixes has been published yet. I also opened a GitHub issue about the release request here: https://github.com/ruby/pathname/issues/94. Would it be possible to make a new pathname release? -- https://bugs.ruby-lang.org/

2 1