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:123795] [Ruby Bug#21685] Unnecessary context-switching, especially bad on multi-core machines.
by jpl-coconut (Jacob Lacouture) 16 Apr '26

16 Apr '26

Issue #21685 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21685: Unnecessary context-switching, especially bad on multi-core machines. https://bugs.ruby-lang.org/issues/21685 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the benchmark takes ~3.6sec on a single-core machine, and ~36sec **(10x slower) on a machine with 2 or more cores** . Initially I thought this was a bug in the implementation of Thread::Queue, but soon realized it relates to how the ruby reschedules threads around system calls. I prepared a fix in [[this branch]](https://github.com/jpl-coconut/ruby/tree/deferred_thread_wait) which is based off ruby 3.4.7. I can apply the fix to a different branch or to master if that's helpful. The fix simply defers suspending the thread until the syscall has been running for some short interval. I chose 100usec initially, but this could easily be made configurable. I pasted raw benchmark results below from a single run (though I did many runs and the results are stable). My CPU is an Apple M4. After the fix: - Single-core performance improves by 55%, from 3.6sec to 2sec. - Adding cores causes performance to be flat (at 2sec), rather than getting 10x slower. - Multi-core context-switch count reduces by 99.995%, from 1.4 million to ~80 - system_time/user_time ratio drops from (1.2 - 1.6) to 0.65 Here are the benchmark results before my change: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1140773 nonvoluntary_ctxt_switches: 9487 real 0m3.619s user 0m1.653s sys 0m1.950s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1400110 nonvoluntary_ctxt_switches: 3 real 0m36.223s user 0m9.380s sys 0m14.927s ``` And after: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 88 nonvoluntary_ctxt_switches: 899 real 0m2.031s user 0m1.209s sys 0m0.743s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 75 nonvoluntary_ctxt_switches: 8 real 0m2.062s user 0m1.279s sys 0m0.783s ``` I was concerned these results might still be reflective of a bug in Thread::Queue, so I also came up with a repro that doesn't rely on it. That one is [[here]](https://gist.github.com/jpl-coconut/aa14e59354abf98f808daaf39baa9a72). Results summary: - Single-core performance improves (this time by only 30%) - Multi-core penalty drops from 4x to 0. - No change to context-switching rates. - system_time/user_time ratio drops from (0.5-1) to 0.15 Before fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.336s user 0m0.211s sys 0m0.118s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m1.424s user 0m0.468s sys 0m0.496s ``` After fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 59 real 0m0.241s user 0m0.202s sys 0m0.032s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.238s user 0m0.195s sys 0m0.035s ``` -- https://bugs.ruby-lang.org/

7 16

[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