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

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

6 14

[ruby-core:125330] [Ruby Bug#22010] Update to Unicode 18.0
by duerst 21 Apr '26

21 Apr '26

Issue #22010 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #22010: Update to Unicode 18.0 https://bugs.ruby-lang.org/issues/22010 * Author: duerst (Martin Dürst) * Status: Open * Assignee: duerst (Martin Dürst) * Target version: 4.1 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Unicode 18.0 has been in alpha since February 2026, which closed on March 31. Beta review is scheduled to start in May. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125326] [Ruby Feature#22008] RUBY_INTERNAL_EVENT_NEWOBJ should run earlier, with fully uninitialized object
by jhawthorn (John Hawthorn) 21 Apr '26

21 Apr '26

Issue #22008 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #22008: RUBY_INTERNAL_EVENT_NEWOBJ should run earlier, with fully uninitialized object https://bugs.ruby-lang.org/issues/22008 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: jhawthorn (John Hawthorn) ---------------------------------------- `RUBY_INTERNAL_EVENT_NEWOBJ` is an internal tracepoint event, accessible only to C. I'd consider it an unstable semi-private API, really intended to be used by only ObjectSpace. The documentation states: * in internal events, **you can not use any Ruby APIs** (even object creations) * Limitations are MRI version specific Basically, it's unsafe to do use any Ruby APIs in the hook. An exception is `rb_profile_frames`, but I believe everything else should not be allowed. Currently the `RUBY_INTERNAL_EVENT_NEWOBJ` hook fires after the object has been assigned its klass, flags, and (sometimes) shape_id. In pseudocode the current `newobj_of` is: ```c VALUE rb_gc_impl_new_obj(..., klass, flags, ...) { obj = freelist_pop_or_alloc(size); obj->flags = flags; obj->klass = klass; return obj; } VALUE newobj_of(klass, flags, shape_id, ...) { VALUE obj = rb_gc_impl_new_obj(..., klass, flags, ...); obj->shape_id = shape_id; if (rb_gc_event_hook_required_p(RUBY_INTERNAL_EVENT_NEWOBJ)) { // hook receives partially initialized object (klass, flags, shape_id, but no other fields) gc_newobj_hook(obj); } return obj; } ``` Instead I would like this to look like the following: ```c VALUE rb_gc_impl_new_obj(...) { VALUE obj = freelist_pop_or_alloc(size); if (rb_gc_event_hook_required_p(RUBY_INTERNAL_EVENT_NEWOBJ)) { // hook receives uninitialized object, a fully 0-initialized T_NONE gc_newobj_hook(obj); } return obj; } VALUE newobj_of(klass, flags, shape_id, ...) { VALUE obj = rb_gc_impl_new_obj(...); obj->flags = flags; obj->shape_id = shape_id; obj->klass = klass; return obj; } ``` Calling the hook with a _partially_ constructed object (klass/shape/flags, but no other attributes set) forces us to include klass/flag/shape_id assignment in the GC API, which prevents several optimizations I'd like to attempt in the next year or so: * Inlining the klass/flags/shape assignment into caller of NEWOBJ macro * Inline allocations in ZJIT (@tekknolagi has asked for the GC to be able to support this) * Eliding reads and modifications to flags/klass/shape, both in C code and ZJIT (should happen automatically from inlining above) * Low-overhead sampling by keeping a freelist or bump pointer of known size https://pypy.org/posts/2025/02/pypy-gc-sampling.html#sampling-approach I want to make this change, however it may cause issues with some allocation profiling gems: * ko1's `allocation_tracer` reads the value_type and klass when called * ddtrace (?) previously tried to use object_id on freshly allocated objects (which was always buggy, crashes reliably in Ruby 4.0), not sure what it does now #21710 * ruby-prof [checks if newly allocated objects are IMEMOs](https://github.com/ruby-prof/ruby-prof/blob/a84326d3b3f248d93b7ab29… (Some previous discussion in #21854). I'm not sure why, it will probably work with this change and simply not skip imemo. Stackprof, Vernier (my profiler), and ObjectSpace.trace_allocations will not have issues as they do not attempt to access the memory of these objects, they only use the address. I'd like to discuss how to make this change. Possible options: * Make the change, gems that try to access flags/klass may crash * Silently disable RUBY_INTERNAL_EVENT_NEWOBJ and introduce a new event or API. This would avoid any crashes, but existing gems would not work * Skip the C optimizations. Disable ZJIT (with a warning?) when RUBY_INTERNAL_EVENT_NEWOBJ is used * Add a `rb_gc_post_alloc(obj)` call to all call sites after the assignment (slow) -- 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) 17 Apr '26

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

3 9

[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