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

[ruby-core:127109] [Ruby Feature#22441] Add Ractor#alive?
by jhawthorn (John Hawthorn) 15 Oct '26

15 Oct '26

Issue #22441 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #22441: Add Ractor#alive? https://bugs.ruby-lang.org/issues/22441 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- I propose adding `Ractor#alive?` as a non-blocking way to ask whether a Ractor has finished. This matches `Thread#alive?`/`Fiber#alive?`. ``` r = Ractor.new { Ractor.receive } r.alive? #=> true r << :done r.join r.alive? #=> false ``` This is already somewhat visible via `Ractor#inspect`, but that's quite awkward. We use this in the test suite. ``` r = Ractor.new{ sleep 1 } r.inspect #=> "#<Ractor:#3 (irb):4 running>" sleep 2 r.inspect #=> "#<Ractor:#3 (irb):4 terminated>" ``` After fork, other Ractors `alive?` will return false, as with `Thread#alive?`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:127115] [Ruby Feature#22444] Ractor.new should use Ractor.shareable_proc semantics for the block
by jhawthorn (John Hawthorn) 14 Oct '26

14 Oct '26

Issue #22444 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #22444: Ractor.new should use Ractor.shareable_proc semantics for the block https://bugs.ruby-lang.org/issues/22444 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- #21557 introduced very well considered rules for `Ractor.shareable_proc`, where locals can be referenced so long as they are never reassigned. However `Ractor.new { ... }` continues to use a more restrictive rule that no local variable access is allowed at all. I'd like to propose that `Ractor.new` follow the same rules as `Ractor.shareable_proc`. This simplifies implementation, and should be simpler for users both because of what it allows and because of consistency. ```ruby outer_var = "ok" Ractor.new { puts outer_var }.join # raise on 4.0, I propose we allow this Ractor.new(outer_var) { |inner_var| puts inner_var }.join # old way to do this, still works # This doesn't add any new abilities, as one could already emulate this with the following on 4.0 pr = Ractor.shareable_proc { puts outer_var } # allowed, because no reassignment to outer_var Ractor.new(pr){ |pr| pr.call }.join # allowed, because pr is shareable reassigned = "bad" Ractor.new { puts reassigned }.join # no change, still raises reassigned = "still bad" ``` `self` continues to be the new `Ractor` object. One additional change here is that previously the proc passed to `Ractor.new(&some_proc)` would actually be mutated to be shareable. I don't think this was intentional and we should remove this behaviour. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126936] [Ruby Feature#22408] Use GNU make instead of nmake for mswin builds
by hsbt (Hiroshi SHIBATA) 14 Oct '26

14 Oct '26

Issue #22408 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #22408: Use GNU make instead of nmake for mswin builds https://bugs.ruby-lang.org/issues/22408 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- The mswin build uses nmake, whose dialect is restrictive. It cannot run jobs in parallel, has no VPATH, and its substitution `$(VAR:a=b)` cannot contain macros. nmake 14.30 (VS 2022) added functions such as `$(subst)` that can, but we cannot use them while the VS 2017 and 2019 toolsets, which come with older nmake, are supported. Keeping `common.mk` and `win32/Makefile.sub` working with it depends on nobu alone, and nobu has said he would like to drop nmake if he could. I have no preference between nmake and GNU make, because I can keep either one working with a coding agent. But `-j` with GNU make would speed up the build, which is very attractive. https://github.com/ruby/ruby/pull/19214 adds `win32/GNUmakefile.sub`, and `make exam` passes with it. These are the times to build Ruby after `configure.bat`, from one run each. | | nmake | GNU make | |---|---|---| | My machine, 16 jobs | 565 s | 131 s | | GitHub Actions `windows-2025-vs2026`, 4 jobs | 616 s | 343 s | `make check` took about the same time as `nmake check` on GitHub Actions (602 s and 550 s), because the tests already run in parallel. Switching does not reduce the Windows specific makefiles, since `GNUmakefile.sub` only takes the place of `Makefile.sub`. GNU make has no official Windows binary. `win32/install-gnumake.cmd` downloads the GNU release, checks its SHA256, and builds `make.exe` with cl.exe in about 15 seconds. `configure.bat` itself still runs nmake. ``` win32\install-gnumake.cmd set PATH=%CD%\.gnumake;%PATH% win32\configure.bat ruby win32\mkgnumakefile.rb make -j16 ``` A Ruby built this way records `--with-make-prog=make` in `RbConfig::CONFIG["configure_args"]`, so `gem install` runs `make` for C extensions. The release package will ship the same script, and `make install` will put the `make.exe` next to `ruby.exe` so that `gem install` finds it. I am unsure whether to keep nmake alongside GNU make or to replace it right away. I would like to hear opinions. My proposal is to support both in Ruby 4.1 and, if nothing goes wrong, to make GNU make the only option in Ruby 4.2. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:127112] [Ruby Feature#22443] Remove multi-line regular expression comments from object inspection
by bkuhlmann (Brooke Kuhlmann) 14 Oct '26

14 Oct '26

Issue #22443 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #22443: Remove multi-line regular expression comments from object inspection https://bugs.ruby-lang.org/issues/22443 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why Hello. 👋 Would it be possible to remove multi-line regular expression comments from object inspection? For example, this is nice for readability via the source code: ``` ruby class Demo PATTERN = / (?: # Start non-capture group. (?<position>[0-9]+) # Position capture group, numbers only. - # Dash. )? # End non-capture group and make it optional. (?<name>[[:word:]-]+) # Name capture group, required. (?: # Non-capture group start. \+ # Plus. (?<meta>[[:word:]\-,=]+) # Meta capture group, required. )? # End non-capture group and make it optional. /x def initialize pattern = PATTERN @pattern = pattern end private attr_reader :pattern end ``` However, the above is quite noisy when inspecting the object. Example: ``` ruby Demo.new #<Demo:0x000000012fed5730 @pattern= / (?: # Start non-capture group. (?<position>[0-9]+) # Position capture group, numbers only. - # Dash. )? # End non-capture group and make it optional. (?<name>[[:word:]-]+) # Name capture group, required. (?: # Non-capture group start. \+ # Plus. (?<meta>[[:word:]\-,=]+) # Meta capture group, required. )? # End non-capture group and make it optional. /x> ``` ## How It would be nice to automatically strip the comments and collapse the newlines for the object when inspecting it. Example: ``` ruby Demo.new #<Demo:0x0000000131d588d8 @pattern=/(?:(?<position>[0-9]+)-)?(?<name>[[:word:]-]+)(?:\+(?<meta>[[:word:]\-,=]+))?/> ``` The above frees up a lot of vertical space -- especially when inspecting multiple objects at once -- so you don't have to scroll so much via the command line. You still get a visual indication that a pattern is used and can jump to the source if you need readability to learn more. ## Notes One solution to the above is to add this private method: ``` def instance_variables_to_inspect = %i[@pattern] ``` The above definitely reduces the verbosity but at the cost of hiding the instance variable. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127110] [Ruby Bug#22442] Lazy loading of error_highlight etc. is skipped in threads and Ractors
by mame (Yusuke Endoh) 14 Oct '26

14 Oct '26

Issue #22442 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22442: Lazy loading of error_highlight etc. is skipped in threads and Ractors https://bugs.ruby-lang.org/issues/22442 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- #21951 made error_highlight / did_you_mean / syntax_suggest lazily loaded. When the lazy loading is triggered concurrently from threads or Ractors, the decoration may be skipped. ```ruby # repro.rb rs = 2.times.map do Ractor.new do nil.upcase rescue => e e.detailed_message(highlight: false) end end rs.each { puts it.value, "" } ``` Expected: ``` $ ruby repro.rb undefined method 'upcase' for nil (NoMethodError) nil.upcase ^^^^^^^ undefined method 'upcase' for nil (NoMethodError) nil.upcase ^^^^^^^ ``` Actual: ``` $ ruby repro.rb undefined method 'upcase' for nil (NoMethodError) nil.upcase ^^^^^^^ undefined method 'upcase' for nil (NoMethodError) ``` Cause: the first caller of `detailed_message` sets a flag when it starts loading. So when another thread or Ractor calls it during the load, it returns without decoration instead of waiting for the load to complete. Fix: fire the `autoload` instead of calling `rb_require_string`, so that the autoload's synchronization prevents the skip. https://github.com/ruby/ruby/pull/19352 Also, because `rb_require_string` was used, a newer version installed by `gem install error_highlight` was not used. Firing the `autoload` respects the monkeypatch of `Kernel#require`, so the newer version of error_highlight will be used. Note: this is why the snippet is not shown in #22439. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127108] [Ruby Bug#22440] Referencing an autoload constant from multiple Ractors dumps core
by mame (Yusuke Endoh) 14 Oct '26

14 Oct '26

Issue #22440 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22440: Referencing an autoload constant from multiple Ractors dumps core https://bugs.ruby-lang.org/issues/22440 * Author: mame (Yusuke Endoh) * Status: Assigned * Assignee: ko1 (Koichi Sasada) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Referencing an autoload constant from multiple Ractors in parallel may cause a SEGV: ```ruby # foo.rb module Foo; end ``` ```ruby # repro.rb autoload :Foo, "./foo" p 8.times.map { Ractor.new { Foo } }.map(&:value) ``` ``` $ ruby repro.rb repro.rb:2: [BUG] Segmentation fault at 0x0000000000000030 ``` Reproduced with GCC 16 on Ubuntu 26.04. Not reproduced with GCC 13 / 15. Cause: * GCC 16 computes the address of the TLS variable (`ruby_current_ec`) at the entry of `rb_vm_opt_getconstant_path`, and reuses it within the function. * When `vm_get_ev_const_chain` blocks waiting for an autoload, the M:N thread scheduler may resume the thread on a different native thread. * After that, `GET_RACTOR()` in `vm_ic_update` (inlined) reads the TLS of the previous native thread, refers to an invalid value, and SEGVs. Proposed fix: pass `ec` (already an argument of `rb_vm_opt_getconstant_path`) to `vm_ic_update`, and use `rb_ec_ractor_ptr(ec)` instead of `GET_RACTOR()`. https://github.com/ruby/ruby/pull/19348 Note: the SEGV in #22439 is this issue, triggered by the autoload of `Ruby::Prism`. Since #22439 also involves another problem, I created this ticket dedicated to the autoload + Ractor issue. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127083] [Ruby Feature#22431] Add `IO#unpack` and `IO#unpack1`
by ntkme (Natsuki Natsume) 14 Oct '26

14 Oct '26

Issue #22431 has been reported by ntkme (Natsuki Natsume). ---------------------------------------- Feature #22431: Add `IO#unpack` and `IO#unpack1` https://bugs.ruby-lang.org/issues/22431 * Author: ntkme (Natsuki Natsume) * Status: Open ---------------------------------------- I would like to have ruby add `IO#unpack` and `IO#unpack1` that effectively does both `IO#read(...)` and `String#unpacking(...)` in one call. This can significantly improve the performance of consuming data in a variable-length encoding format (E.g. LEB128) from a non-peekable `IO` stream (e.g. network/stdio). In a streaming `IO` with variable-length encoding, today it requires the consumer to scan the stream byte-by-byte to precisely finding the ending of a variable-length segment (E.g. LEB128). If we can have `IO#unpack`/`IO#unpack1`, it will be able to precisely consume a variable-length segment by itself, without needing a two-step solution that requires lots of intermediate ruby object allocation. --- Here is a read world example: LEB128 pack/unpack was recently added by: https://bugs.ruby-lang.org/issues/21785 A very common use case for this is LEB128 delimited payload streaming. In real world it can be a LEB128 delimited protobuf message stream. For example: ``` length, payload, length, payload, length, payload... ``` In pseudo code, reading and writing such stream would look like: ```ruby def write(payload, io) io.write([payload.length].pack('R')) io.write(payload) end def read(io) length = io.unpack1('R') # ^ This method does not exist, which makes the real world implementation slower and more complicated. # See attached benchmark.rb for working implementations. io.read(length) end ``` --- See attached `benchmark.rb`, which demonstrates the limitation of native unpacking for LEB128: ``` ruby 4.1.0dev (2026-10-12T17:01:34Z master 98fd04f76c) +YJIT +PRISM [arm64-darwin27] Warming up -------------------------------------- write varint (pure ruby) 12.167k i/100ms write leb128 (native) 15.710k i/100ms Calculating ------------------------------------- write varint (pure ruby) 124.060k (± 1.6%) i/s (8.06 μs/i) - 620.517k in 5.001746s write leb128 (native) 157.036k (± 1.1%) i/s (6.37 μs/i) - 785.500k in 5.002040s Comparison: write leb128 (native) : 157035.9 i/s write varint (pure ruby): 124060.1 i/s - 1.27x slower ruby 4.1.0dev (2026-10-12T17:01:34Z master 98fd04f76c) +YJIT +PRISM [arm64-darwin27] Warming up -------------------------------------- read varint (pure ruby) 42.025k i/100ms read leb128 (native) 20.246k i/100ms Calculating ------------------------------------- read varint (pure ruby) 423.775k (± 0.8%) i/s (2.36 μs/i) - 2.143M in 5.057579s read leb128 (native) 201.781k (± 1.4%) i/s (4.96 μs/i) - 1.012M in 5.016818s Comparison: read varint (pure ruby): 423774.9 i/s read leb128 (native) : 201781.3 i/s - 2.10x slower ``` On the writing path, LEB128 packing outperforms the pure ruby implementation, which is expected. However, on the reading path, LEB128 unpacking does not help the performance due to the "variable length" nature of LEB128, which requires finding exact end of the LEB128 before it can be unpacked: ``` ruby buffer = [] loop do byte = io.readbyte buffer << byte break if byte < 0x80 # this is the last byte of a LEB128 number end buffer.pack('C*').unpack1('R') ``` Because of the extra intermediate steps that locate the ending of LEB128 and build a buffer, using LEB128 unpacking in a streaming context ended up to be much slower than a pure ruby implementation that does both scanning and decoding in a single loop: ``` ruby value = bits = 0 loop do byte = io.readbyte value |= (byte & 0x7f) << bits bits += 7 break if byte < 0x80 end value ``` Therefore, if we can have a native ruby method that does scanning and decoding from `IO` in one shot, it would be a huge improvement. ``` ruby io.unpack1('R') ``` ---Files-------------------------------- benchmark.rb (1.64 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:127103] [Ruby Bug#22438] mkmf.rb do not work with /home mounted with noexec
by mbideau (Michael Bideau) 14 Oct '26

14 Oct '26

Issue #22438 has been reported by mbideau (Michael Bideau). ---------------------------------------- Bug #22438: mkmf.rb do not work with /home mounted with noexec https://bugs.ruby-lang.org/issues/22438 * Author: mbideau (Michael Bideau) * Status: Open * ruby -v: ruby 3.3.8 (2025-04-09 revision b200bad6cd) [x86_64-linux-gnu] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When trying to install a *vagrant* plugin (here *vagrant-libvirt*), it uses the file **mkmf.rb** (here `/opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb`) and this fail with the following error message: > Vagrant failed to install the requested plugin because development tools are required for installation but are not currently installed on this machine. Please install development tools and then try this command again. It is the user facing error message that is from the following underlying command: ``` /opt/vagrant/embedded/bin/ruby --verbose extconf.rb checking for pkg-config for libvirt... /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:480:in `try_do': The compiler failed to generate an executable file. (RuntimeError) You have to install development tools first. from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:573:in `try_link0' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:591:in `try_link' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:683:in `try_ldflags' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:1896:in `block in pkg_config' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:983:in `block in checking_for' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:344:in `block (2 levels) in postpone' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:314:in `open' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:344:in `block in postpone' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:314:in `open' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:340:in `postpone' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:982:in `checking_for' from /opt/vagrant/embedded/lib/ruby/3.3.0/mkmf.rb:1862:in `pkg_config' from extconf.rb:5:in `<main>' ``` The mentioned `try_do` function is where the issue is. Here is its code (as the ruby version 3.3.8): ```ruby def try_do(src, command, *opts, &b) unless have_devel? raise <<MSG The compiler failed to generate an executable file. You have to install development tools first. MSG end begin src = create_tmpsrc(src, &b) xsystem(command, *opts) ensure log_src(src) end end ``` Which is called by `try_link0` function that has the following code: ```ruby def try_link0(src, opt="", *opts, &b) # :nodoc: exe = CONFTEST+$EXEEXT cmd = link_command("", opt) if $universal require 'tmpdir' Dir.mktmpdir("mkmf_", oldtmpdir = ENV["TMPDIR"]) do |tmpdir| begin ENV["TMPDIR"] = tmpdir try_do(src, cmd, *opts, &b) ensure ENV["TMPDIR"] = oldtmpdir end end else try_do(src, cmd, *opts, &b) end and File.executable?(exe) or return nil exe ensure MakeMakefile.rm_rf(*Dir["#{CONFTEST}*"]-[exe]) end ``` So you can see, if my understanding is correct, that the environment variable`TMPDIR`, despite being set, is never used/honored to execute the command. The command is still running in the current working directory, and the `TMPDIR` is ignored/useless. In my case the current working directory is `~/.vagrant.d/gems/3.3.8/gems/ruby-libvirt-0.8.4/ext/libvirt` which is in my */home* mounted with `noexec`. This makes `File.executable?(exe)` (`exe` is the compiled file) returning `false` because the source and the compiled file (even if they are just to test) end up in my working directory and not in the temporary directory specified with the environment variable **TMPDIR** which have `exec` permission. So I suggest to always use a temporary directory to execute all the tests contained in this code file **mkmf.rb** and to actually honor `TMPDIR` when defined. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127100] [Ruby Bug#22436] Array#zip with a method_missing-based argument leaks a stale block handler (segfault when the next C-called method yields)
by 0599jiangyc＠gmail.com (Yuancheng Jiang) 14 Oct '26

14 Oct '26

Issue #22436 has been reported by 0599jiangyc(a)gmail.com (Yuancheng Jiang). ---------------------------------------- Bug #22436: Array#zip with a method_missing-based argument leaks a stale block handler (segfault when the next C-called method yields) https://bugs.ruby-lang.org/issues/22436 * Author: 0599jiangyc(a)gmail.com (Yuancheng Jiang) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code: ```rb o = Object.new def o.method_missing(*) = nil # Array#zip calls o.each via method_missing out = Object.new def out.write(*) = nil def out.puts(*) = yield # receives a block it was never given $stdout = out [1].zip(o) puts 1 # Kernel#puts -> $stdout.puts gets a stale ifunc block ``` Resulted in this output (release build, also ruby 3.2.3): ``` min.rb:6: [BUG] Segmentation fault at 0x0000000000000018 -- Control frame information ----------------------------------------------- c:0005 p:---- s:0021 e:000020 l:n b:---- r:(nil) IFUNC :puts c:0004 p:0002 s:0018 e:000017 l:y b:0001 r:(nil) METHOD min.rb:6 [FINISH] c:0003 p:---- s:0013 e:000012 l:y b:0001 r:(nil) CFUNC :puts c:0002 p:0062 s:0008 E:001df0 l:n b:---- r:(nil) EVAL min.rb:10 [FINISH] -- C level backtrace information ------------------------------------------- ruby(vm_yield_with_cfunc+0x329) ../vm_insnhelper.c:5273 ruby(vm_invoke_ifunc_block+0x1a9) ../vm_insnhelper.c:5537 ruby(vm_sendish+0xea) ../vm_insnhelper.c:6290 ruby(rb_vm_exec) vm.c:2884 ruby(vm_call0_body+0xeb2) ../vm_eval.c:225 ruby(rb_call0) ../vm_eval.c:577 ruby(rb_funcallv_kw+0x8e) ../vm_eval.c:896 ruby(vm_call_cfunc_with_frame_) ../vm_insnhelper.c:3906 ``` With `-DRUBY_DEBUG=1` an even smaller program trips the VM assertion: ```rb o = Object.new def o.method_missing(*) = nil [1].zip(o) puts 1 ``` ``` ../vm_core.h:1849: Assertion Failed: VM_BH_IFUNC_P:imemo_type_p(captured->code.val, imemo_ifunc) ruby 4.1.0dev (2026-10-11T06:59:58Z master 46033eff6c) +PRISM [x86_64-linux] ruby(rb_assert_failure) ruby(vm_block_handler_type+0x15b) ../vm_core.h:1849 ruby(vm_block_handler_verify+0xd) ../vm_core.h:1903 ruby(rb_call0) vm.c:327 ruby(rb_funcallv_kw+0xdd) ../vm_eval.c:896 ruby(vm_call_cfunc_with_frame_+0x27b) ../vm_insnhelper.c:3906 ``` The same thing also silently drops the block. `method_missing(:each, &b)` called from `Array#zip` gets `b == nil`. Analysis: `take_items` (array.c) calls `rb_check_block_call`, and `rb_iterate0` sets `ec->passed_block_handler` to an ifunc block captured in the `zip` frame. When `each` is missing, `check_funcall_missing` -> `check_funcall_exec` -> `call_method_entry` (vm_method.c) takes the passed block handler, calls `rb_vm_call_kw` (so `method_missing` runs with no block), and then *restores* the handler. Nothing consumes it after that. After `zip` returns, `ec->passed_block_handler` still points at the popped frame's captured block. The next C-level `rb_funcall*` (here Kernel#puts -> `$stdout.puts`) picks it up in `vm_passed_block_handler()` and passes it as the callee's block. `call_method_entry`'s save/restore suits `respond_to_missing?`, but on the final `method_missing` call the block should be passed to that method, not restored. To reproduce: ``` ruby ./min.rb ``` Commit: ``` 46033eff6c01f05afa2505452fdbf4bea7ca9c6d (also reproduced on 3296d5c99c and ruby 3.2.3) ``` Build configuration: ``` ../configure --prefix=... --disable-install-doc cflags="-fsanitize=address -fno-omit-frame-pointer -DUSE_MN_THREADS=0" cppflags="-DRUBY_DEBUG=1" optflags="-O1" debugflags="-g" (segfault also reproduces with a non-debug build and with Ubuntu's packaged ruby 3.2.3) ``` Operating System: ``` Ubuntu 24.04.4 LTS (x86_64), Docker image fusion-fuzz-ruby:latest ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:127099] [Ruby Bug#18782] Race conditions in autoload when loading the same feature with multiple threads.
by mame (Yusuke Endoh) 14 Oct '26

14 Oct '26

Issue #18782 has been updated by mame (Yusuke Endoh). The global autoload mutex introduced for this issue causes "deadlock; recursive locking" and [BUG] under a Fiber scheduler. See [Bug #22435]. I think this issue can be fixed without the global mutex by swapping the order of the checks in `check_autoload_required`: whether the feature is provided first, then whether another thread is autoloading it. https://github.com/ruby/ruby/pull/19335 ---------------------------------------- Bug #18782: Race conditions in autoload when loading the same feature with multiple threads. https://bugs.ruby-lang.org/issues/18782#change-119497 * Author: ioquatix (Samuel Williams) * Status: Closed * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I have identified several race conditions in the autoload code. 1. It's possible to race on adding and then deleting items in `autoload_featuremap`. When this happens, two threads will try to load the same file with different autoload data and deadlock. 2. When finishing autoload, it's necessary to clear `ele->state` before setting constants. If this is not synchronised, a thread can see the cleared `ele->state` before seeing the constants and assume the constant is not being autoloaded and then fail with `NameError`. This test case can reproduce both cases: ``` # test.rb autoload_path = File.join(__dir__, "foobar.rb") File.write(autoload_path, 'module Foo; end; module Bar; end') 100_000.times do $stderr.puts "--------------------" autoload :Foo, autoload_path autoload :Bar, autoload_path t1 = Thread.new {Foo} t2 = Thread.new {Bar} t1.join t2.join Object.send(:remove_const, :Foo) Object.send(:remove_const, :Bar) $LOADED_FEATURES.delete(autoload_path) end ``` Example failure of case (1): ``` -------------------- (success) autoload_by_someone_else ele=0x55f33b806a30 ele->state=(nil) autoload_by_someone_else ele=0x55f33b806a30 ele->state=(nil) check_autoload_required 2 autoload_by_someone_else ele=0x55f33b806a30 ele->state=0x7fdd678be780 check_autoload_required 4 autoload_by_someone_else ele=0x55f33b806a30 ele->state=0x7fdd678be780 check_autoload_required 4 ele=0x55f33b806a30 ele->state=0x7fdd678be780 = NULL check_autoload_required 4 -------------------- (failure) autoload_by_someone_else ele=0x55f33b806a30 ele->state=(nil) autoload_by_someone_else ele=0x55f33b6e8f40 ele->state=(nil) check_autoload_required 2 check_autoload_required 3 autoload_by_someone_else ele=0x55f33b806a30 ele->state=0x7fdd6779d780 check_autoload_required 1 autoload_by_someone_else ele=0x55f33b806a30 ele->state=0x7fdd6779d780 check_autoload_required 1 ele=0x55f33b806a30 ele->state=0x7fdd6779d780 = NULL ele=0x55f33b6e8f40 ele->state=0x7fdd678be780 = NULL ../test.rb:12:in `join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x000055f33b771250 main thread:0x000055f33b66e090 * #<Thread:0x00007fdd6a2cb0b0 sleep_forever> rb_thread_t:0x000055f33b66e090 native:0x00007fdd6a71c3c0 int:0 * #<Thread:0x00007fdd676e0090 ../test.rb:9 sleep_forever> rb_thread_t:0x000055f33b770ff0 native:0x00007fdd6789e640 int:1 mutex:0x000055f33b7c5100 cond:1 depended by: tb_thread_id:0x000055f33b66e090 * #<Thread:0x00007fdd676e1238 ../test.rb:10 sleep_forever> rb_thread_t:0x000055f33b771250 native:0x00007fdd679bf640 int:0 from ../test.rb:12:in `block in <main>' from ../test.rb:4:in `times' from ../test.rb:4:in `<main>' make: *** [uncommon.mk:1250: runruby] Error 1 ``` Example failure of case (2): ``` [0x7f175fe5b0c8] rb_autoload_str mod=Object id=Foo file="/home/samuel/Projects/ioquatix/ruby/foobar.rb" [0x7f175fe5b0c8] rb_autoload_str const_set mod=Object id=Foo file="/home/samuel/Projects/ioquatix/ruby/foobar.rb" [0x7f175fe5b0c8] rb_autoload_str mod=Object id=Bar file="/home/samuel/Projects/ioquatix/ruby/foobar.rb" [0x7f175fe5b0c8] rb_autoload_str const_set mod=Object id=Bar file="/home/samuel/Projects/ioquatix/ruby/foobar.rb" [0x7f175fe61d88] rb_const_search_from value == Qundef -> autoloading [0x7f175fe61e78] rb_const_search_from value == Qundef -> autoloading [0x7f175fe61e78] Assigning constants... [0x7f175fe61d88] rb_const_search_from value == Qundef -> autoloading [0x7f175fe61e78] autoload_const_set name=:Foo value=Foo [0x7f175fe61e78] autoload_const_set name=:Bar value=Bar #<Thread:0x00007f175fe61d88 ../test.rb:11 run> terminated with exception (report_on_exception is true): ../test.rb:11:in `block (2 levels) in <main>': uninitialized constant Bar (NameError) ../test.rb:11:in `block (2 levels) in <main>': uninitialized constant Bar (NameError) make: *** [uncommon.mk:1250: runruby] Error 1 ``` These failures are very uncommon but it does impact Ruby as far back as 2.7, and probably earlier. ---Files-------------------------------- 0001-Add-RUBY_VM_CRITICAL_SECTION-for-detecting-unexpecte.patch (2.07 KB) 0002-Prevent-race-between-GC-mark-and-autoload-setup.patch (1.01 KB) 0003-Protect-race-on-autoload-state.patch (10.6 KB) 0004-Increase-timeout-for-debug-tests.patch (910 Bytes) 0005-Revert-removal-of-non-conditional-xfree.patch (691 Bytes) -- https://bugs.ruby-lang.org/

1 0