- ruby-core - ml.ruby-lang.org

[ruby-core:124864] [Ruby Misc#21922] Permissions for committers for default/bundled/unbundled gems repositories
by Eregon (Benoit Daloze) 15 Apr '26

15 Apr '26

Issue #21922 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21922: Permissions for committers for default/bundled/unbundled gems repositories https://bugs.ruby-lang.org/issues/21922 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I noticed recently that the team `ruby-committers` on GitHub no longer has write access to at least: * https://github.com/ruby/benchmark * https://github.com/ruby/cmath * https://github.com/ruby/curses * https://github.com/ruby/dbm * https://github.com/ruby/e2mmap * https://github.com/ruby/gdbm * https://github.com/ruby/getoptlong * https://github.com/ruby/iconv * https://github.com/ruby/mathn * https://github.com/ruby/mutex_m * https://github.com/ruby/net-ftp * https://github.com/ruby/net-pop * https://github.com/ruby/net-telnet * https://github.com/ruby/observer * https://github.com/ruby/pathname (marked as maintained by @akr but they don't reply on GitHub, there is also an unclear relation with core Pathname [which still hasn't been resolved](https://github.com/ruby/pathname/issues/66) and is causing warnings for months) * https://github.com/ruby/prime * https://github.com/ruby/pstore * https://github.com/ruby/readline * https://github.com/ruby/readline-ext * https://github.com/ruby/ruby2_keywords * https://github.com/ruby/scanf * https://github.com/ruby/sdbm * https://github.com/ruby/set * https://github.com/ruby/shell * https://github.com/ruby/syck * https://github.com/ruby/sync * https://github.com/ruby/thwait * https://github.com/ruby/tk * https://github.com/ruby/tracer * https://github.com/ruby/webrick * https://github.com/ruby/win32api * https://github.com/ruby/xmlrpc This list is from a couple cases I noticed myself + [all repos](https://github.com/orgs/ruby/repositories?q=mirror%3Afalse+fork%3Afa… - [those committers have access](https://github.com/orgs/ruby/teams/ruby-committers/repositories) - [repos with known maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md)) I filtered manually so there could be some mistake(s), though I tried to check carefully. I am certain CRuby committers had access to some of these repositories (e.g. I merged PRs there), but not sure about all, some might already not have had write access for CRuby committers. It seems only the 4 owners of the Ruby GitHub organization have write access to these repositories. What motivated these changes? I believe it is valuable that all CRuby committers can merge to default/bundled/unbundled gems repositories *without active maintainers*, as it was before. There is [this list](https://github.com/ruby/ruby/blob/master/doc/maintainers.md) to define maintainers, though it's a little bit outdated and inaccurate. It's fine enough for this issue though. (A better definition IMO for active maintainers would be maintainers would actually respond to PRs and issues on GitHub to these repositories otherwise they are effectively not maintaining that repository, at least from an external perspective.) IOW it seems unreasonable to always have to ask one of the 4 owners of the Ruby GitHub organization to merge a PR to such repositories, as it would be a significant overhead for committers and for owners, and it would delay merging PRs significantly. I'm thinking for example to * documentation PRs ([many for pathname](https://github.com/ruby/pathname/pulls)) which really shouldn't need an owner to merge * PRs to improve/fix the CI ([example](https://github.com/ruby/readline-ext/pull/29)) * PRs fixing compatibility with recent changes in ruby's master branch * etc. Yet another way to see this is many default/bundled/unbundled gems do not have active maintainers. AFAIK so far in such cases then all CRuby committers could help, but this seems no longer the case. (FWIW I saw there a `default-gems-contributor` team with 3 people, which explains why they can merge PRs to some repositories that ruby committers can't for example.) -- https://bugs.ruby-lang.org/

4 9

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

15 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/

1 0

[ruby-core:125279] [Ruby Bug#22004] parse.y doesn't executes loop body with `while true || true` condition
by Earlopain (Earlopain _) 15 Apr '26

15 Apr '26

Issue #22004 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22004: parse.y doesn't executes loop body with `while true || true` condition https://bugs.ruby-lang.org/issues/22004 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-15T13:47:25Z master d077df24a2) +PRISM [x86_64-linux] * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- ```rb while true || true puts 1 end ``` This should never exit but with parse.y, the body is never executed. It seems to happen when one of the conditions is a truthy literal. Something similar happens with `unitl`: ```rb until false && true puts 1 end ``` By moving the literals out to methods that just return them, it behaves like I would expect. Seems to have started happening in Ruby 3.3. -- https://bugs.ruby-lang.org/

1 0

[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) 15 Apr '26

15 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 2

[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:125276] [Ruby Bug#22003] .bundle extensions not built when doing out-of-source build
by Kulikjak (Jakub Kulik) 15 Apr '26

15 Apr '26

Issue #22003 has been reported by Kulikjak (Jakub Kulik). ---------------------------------------- Bug #22003: .bundle extensions not built when doing out-of-source build https://bugs.ruby-lang.org/issues/22003 * Author: Kulikjak (Jakub Kulik) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [amd64-solaris2.11] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi, I encountered a pretty edge case extension build bug. When building Ruby out-of-source and executing the configure script with a full path in a workspace that contains "test" in its name, it fails to build all the extensions in the `.bundle/gems` directory. It can be easily reporoduced with the following: ``` > pwd /builds/testing/components/ruby/ruby-40 > mkdir build > cd build > /builds/testing/components/ruby/ruby-40/ruby-4.0.2/configure ... > /usr/gnu/bin/make -j 20 ... <the stuff in the .bundle directory is not built> ``` When doing it this way, the `srcdir` variable in the Makefile will be an absolute path, which is then used in `ext/configure-ext.mk` target and in `configure-ext.mk.tmpl` `Dir.glob` call, where the following line: ``` % next if extconf.any?{|f| f.include?(".bundle/gems") && f.include?("test") } ``` makes it omit all the extensions in the ".bundle/gems" directory. The problem is not there when I use a relative path (`../ruby-4.0.2/configure`) or when building directly in `ruby-4.0.2` (because the `srcdir` is relative in those cases). -- https://bugs.ruby-lang.org/

1 0

[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:125270] [Ruby Misc#22001] Adding TruffleRuby in the CI of all default & bundled gems
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #22001 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #22001: Adding TruffleRuby in the CI of all default & bundled gems https://bugs.ruby-lang.org/issues/22001 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to add TruffleRuby (i.e. `ruby-version: truffleruby`, the latest release for improved stability) in the CI of all default & bundled gems. I'm tracking the progress in https://github.com/truffleruby/truffleruby/issues/2644. The reason is default & bundled gems are more likely to depend on CRuby internals or CRuby specifics, and have a very large blast readius, and so adding TruffleRuby there would help to avoid such gems breaking unknowingly on TruffleRuby, which has happened a number of times in the past (and similarly on JRuby). The concrete issue is that for some gems without active maintainers (such as in #21922 and more) it can take a (sometimes very) long time to merge the PR adding TruffleRuby in CI. How can we solve this? I also don't want TruffleRuby being in CI to be any kind of burden, so if there is any issue with it more frequent than other Ruby versions in CI, it seems fair to remove it or use `continue-on-error: true` or just ignore the failure. If removing, my only request would be if possible to include `@eregon` in the PR description removing the job so I can take a look. To help keeping CIs green I use [truffleruby-gem-tracker](https://github.com/truffleruby/truffleruby-gem-tra… and I try to check it regularly to fix any failure. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125117] [Ruby Feature#21963] A solution to completely avoid allocated-but-uninitialized objects
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #21963 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21963: A solution to completely avoid allocated-but-uninitialized objects https://bugs.ruby-lang.org/issues/21963 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- A common issue when defining a class is to handle allocated-but-uninitialized objects. For example: ```ruby obj = MyClass.allocate obj.some_method ``` This can easily segfault for classes defined in C and raise an unclear exception for classes defined in Ruby. As a workaround many core (and non-core) classes add a check that they are initialized in *every* instance method. This is suboptimal for performance and correctness, classes should not need to care about allocated-but-uninitialized objects. Fundamentally, to solve this we need to guarantee that after the allocation function is used that either `initialize`, `initialize_dup` or `initialize_clone` is called. And we can't guarantee that for `Class#allocate`. The current workarounds are: * `undef allocate`, but this does not prevent `Class.instance_method(:allocate).bind_call(Foo)`. * `rb_undef_alloc_func()` but this breaks `dup`, `clone` and `Marshal`. The idea is to have in addition of the `public alloc function` (in `rb_classext_struct.as.class.allocator`) an `internal alloc function`. Then: * `Class#new`, `dup`, `clone` and `Marshal` always use the internal alloc function, because they guarantee to call `initialize`, `initialize_dup` or `initialize_clone`. * `rb_define_alloc_func()` sets both fields. * `rb_undef_alloc_func()` sets both fields. * `rb_get_alloc_func()` reads the public alloc function (unchanged) * `Class#allocate` uses the public alloc function (unchanged) We add a new method on `Class`, for example `Class#safe_initialization`, which: * Sets the public alloc function to `UNDEF_ALLOC_FUNC`, same as `rb_undef_alloc_func()`, so `Class#allocate` and `rb_get_alloc_func()` will raise if they are used (as they are unsafe). * Preserves the internal alloc function so `Class#new`, `dup`, `clone` and `Marshal` keep working. After that the class has fully safe intialization and does not need to worry about allocated-but-uninitialized objects anymore. From https://bugs.ruby-lang.org/issues/21852#note-7 -- https://bugs.ruby-lang.org/

2 7