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

[ruby-core:126842] [Ruby Bug#22378] `Ractor::IsolationError` in code not using Ractors
by Earlopain (Earlopain _) 23 Sep '26

23 Sep '26

Issue #22378 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22378: `Ractor::IsolationError` in code not using Ractors https://bugs.ruby-lang.org/issues/22378 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-23T07:42:54Z master 8cdc7b5957) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb # Reduced from the `httpx` gem @var = Class.new.freeze.dup @var.instance_variable_set(:@test, 123) ``` I expect this code to succeed. dup returns an unfrozen copy, so I should be able to set instance variables on it. However, I get the following error even though the code is ractor-free: ``` test.rb:2:in 'Kernel#instance_variable_set': can't modify instance variables of a shareable Class (Ractor::IsolationError) ``` It works on 4.0 but fails on current master. Behaviour changed recently, maybe #22291, but I haven't confirmed it. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126449] [Ruby Bug#22254] [Prism] Clang UBSan reports NULL/0 memcpy while serializing empty strings
by yqtian (Yongqiang Tian) 23 Sep '26

23 Sep '26

Issue #22254 has been reported by yqtian (Yongqiang Tian). ---------------------------------------- Bug #22254: [Prism] Clang UBSan reports NULL/0 memcpy while serializing empty strings https://bugs.ruby-lang.org/issues/22254 * Author: yqtian (Yongqiang Tian) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-20T02:56:29Z master ed0b427b4b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I found a public `Prism.dump` path that passes a null source and zero length to `memcpy` in Prism's buffer helper. Clang's `nonnull-attribute` sanitizer reports the call because the effective glibc declaration marks the first two `memcpy` arguments as nonnull. I have not observed a crash, output corruption, or an ordinary non-sanitized failure. I am reporting this as a C correctness/toolchain-contract issue, not a security issue. #### Environment ```text x86-64 Ubuntu Clang 18.1.3 Ruby revision: ed0b427b4ba3c776c763d2673070e88372b2096a Relevant sanitizer: -fsanitize=nonnull-attribute Optimization: -O1 ``` I also checked Ruby HEAD `4012a96bf084d035bf582d58c7dafb31f4762ac6` and the corresponding Prism HEAD `3ea210b30108432b8b75b979872f4fa3c23acb7b`; the source site was unchanged. #### Reproduction From a Ruby checkout, create an out-of-tree build with the same flags used in the validation: ```sh ./autogen.sh mkdir build-ubsan cd build-ubsan ../configure \ CC=clang-18 \ CXX=clang++-18 \ CFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" \ CXXFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all -fno-omit-frame-pointer -g -O1" \ LDFLAGS="-fsanitize=nonnull-attribute,returns-nonnull-attribute,nullability-arg,nullability-return,nullability-assign -fsanitize-recover=all" \ optflags="-O1" \ debugflags="-g" \ --disable-install-doc \ --with-baseruby=/usr/bin/ruby make -j4 UBSAN_OPTIONS=print_stacktrace=0:halt_on_error=0:report_error_type=1 \ ruby ../tool/runruby.rb -- -rprism -e 'Prism.dump("//")' ``` Clang reports: ```text prism/buffer.c:86:40: runtime error: null pointer passed as argument 2, which is declared to never be null ``` Other reproducing inputs include `%r{}`, `//im`, and an empty quoted symbol. Nonempty regexps and symbols, an ordinary empty string, and `%q[]` were clean controls. #### Cause Some Prism node fields use a null-backed empty string representation. `pm_serialize_string` passes the source and zero length through `pm_buffer_append_bytes` to: ```c static PRISM_INLINE void pm_buffer_append(pm_buffer_t *buffer, const void *source, size_t length) { size_t cursor = buffer->length; if (pm_buffer_append_length(buffer, length)) { memcpy(buffer->value + cursor, source, length); } } ``` A sink-side repair is: ```c if (pm_buffer_append_length(buffer, length)) { if (length > 0) { memcpy(buffer->value + cursor, source, length); } } ``` Another possibility is to skip `pm_buffer_append_bytes` when `length == 0` in the serialization template, preserving a stricter buffer-helper invariant. Should the buffer append helpers define a zero-length append as a no-op even when the source is null, or should the serialization caller filter null-backed empty strings? #### Validation I built unmodified and guarded trees with identical Docker/compiler/configure flags. The reproducing `Prism.dump` inputs report in the unmodified build and are clean in both recover and `halt_on_error=1` modes after adding the buffer guard. The unmodified and guarded builds produced byte-identical output for `Prism.dump("//")`: ```text SHA-256 eff5e01617aa527a49aa3b900589b163e4e396807ba252e8440c8a8fbfe047a5 ``` The same native test set passed in both builds, including 1,003 Prism dump tests with 403,474 assertions, plus Prism freeze/parse and Ruby eval/proc/syntax tests. The guarded build produced no `buffer.c` report in this test set. I would be happy to prepare a patch after confirming whether the preferred repair belongs in the common buffer helper or the serialization template. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:126825] [Ruby Bug#22340] Win32: File.stat succeeds on symbolic-link loops on Windows
by nobu (Nobuyoshi Nakada) 23 Sep '26

23 Sep '26

Issue #22340 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22340: Win32: File.stat succeeds on symbolic-link loops on Windows https://bugs.ruby-lang.org/issues/22340 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- On Windows, `File.stat` succeeds on a self-referential symbolic link instead of raising `Errno::ELOOP`, and `File.exist?` returns `true`. Opening the same link raises `Errno::ELOOP`. I noticed this while adding symbolic-link tests to FileUtils, whose Windows CI reported the unexpected `File.exist?` result. ## Reproduction ````ruby require 'tmpdir' Dir.mktmpdir do |dir| Dir.chdir(dir) do File.symlink('a', 'a') p File.readlink('a') # => "a" p File.exist?('a') # => true; expected false p File.stat('a') # succeeds; expected Errno::ELOOP File.open('a') # raises Errno::ELOOP ensure File.unlink('a') if File.symlink?('a') end end ```` `File.lstat('a')` should continue to succeed and identify the entry as a symbolic link. ## Cause In `winnt_stat`, failure to open the resolved path falls back to `stat_by_find` unless `open_error` matches one of the listed errors. The symbolic-link-following implementation introduced in f5b96e594c769cf309b70fd7736caaf90372a3b6 retained this fallback, which was intended to handle sharing violations for files such as `pagefile.sys`. `ERROR_CANT_RESOLVE_FILENAME` is not listed, so a symbolic-link loop also reaches the fallback, which retrieves information about the link itself and reports success. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126760] [Ruby Bug#22330] heap uaf from string.encode()
by danielchong (Daniel Chong) 23 Sep '26

23 Sep '26

Issue #22330 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #22330: heap uaf from string.encode() https://bugs.ruby-lang.org/issues/22330 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0-dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, a heap UAF seems possible in string's encode function. PoC ``` s = "あ" * 4000 s.encode("US-ASCII", fallback: proc { |c| s.replace("Z" * (16 * 1024 * 1024)) "?" }) ``` ASAN output (truncated): ``` ERROR: AddressSanitizer: heap-use-after-free ... READ of size 1 #0 transcode_restartable0 transcode.c:592:36 (*in_p) #1 transcode_restartable transcode.c:828 #2 rb_transcoding_convert transcode.c:864 #3 trans_sweep transcode.c:1191 #4 rb_trans_conv transcode.c:1281 #5 rb_econv_convert0 transcode.c:1400 #6 rb_econv_convert transcode.c:1508 #7 transcode_loop transcode.c:2417 (goto resume -> rb_econv_convert) #8 str_transcode0 transcode.c:2877 #9 str_transcode transcode.c:2907 #10 str_encode transcode.c:2973 freed by thread T0 here: #15 proc_fallback transcode.c:2340 (rb_proc_call -> user code reallocs source) #16 transcode_loop_fallback_try transcode.c:2366 #18 transcode_loop transcode.c:2433 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126818] [Ruby Bug#22338] [Backport] win32: create directory symlinks for relative directory targets
by nobu (Nobuyoshi Nakada) 23 Sep '26

23 Sep '26

Issue #22338 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22338: [Backport] win32: create directory symlinks for relative directory targets https://bugs.ruby-lang.org/issues/22338 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/pull/17545 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126833] [Ruby Bug#22377] compile.c: `getlocal` not turned into `getlocal_WC_0`
by alanwu (Alan Wu) 23 Sep '26

23 Sep '26

Issue #22377 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #22377: compile.c: `getlocal` not turned into `getlocal_WC_0` https://bugs.ruby-lang.org/issues/22377 * Author: alanwu (Alan Wu) * Status: Open * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: DONTNEED ---------------------------------------- Missed by the "operands_unification" pass, somehow. See 0023 below: ```text $ ./miniruby --parser=parse.y --dump=insns -e ' assign = ->(outer) { m = Module.new m.set_temporary_name("m") # non-leaf call, so the next getlocal needs a patch point outer::M = m [m.name, outer::M.name] }' == disasm: #<ISeq:<main>@-e:1 (1,0)-(7,9)> local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 1] assign@0 0000 putspecialobject 1 ( 2)[Li] 0002 send <calldata!mid:lambda, argc:0, FCALL>, block in <main> 0005 dup 0006 setlocal_WC_0 assign@0 0008 leave == disasm: #<ISeq:block in <main>@-e:2 (2,17)-(7,9)> local table (size: 2, argc: 1 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 2] outer@0<AmbiguousArg>[ 1] m@1 0000 putnil ( 3)[LiBc] 0001 opt_getconstant_path <ic:0 Module> 0003 opt_new <calldata!mid:new, argc:0, ARGS_SIMPLE>, 10 0006 opt_send_without_block <calldata!mid:initialize, argc:0, FCALL|ARGS_SIMPLE> 0008 jump 13 0010 opt_send_without_block <calldata!mid:new, argc:0, ARGS_SIMPLE> 0012 swap 0013 pop 0014 setlocal_WC_0 m@1 0016 getlocal_WC_0 m@1 ( 4)[Li] 0018 dupchilledstring "m" 0020 opt_send_without_block <calldata!mid:set_temporary_name, argc:1, ARGS_SIMPLE> 0022 pop * 0023 getlocal m@1, 0 ( 5)[Li] 0026 getlocal_WC_0 outer@0 0028 setconstant :M 0030 getlocal_WC_0 m@1 ( 6)[Li] 0032 opt_send_without_block <calldata!mid:name, argc:0, ARGS_SIMPLE> 0034 getlocal_WC_0 outer@0 0036 putobject false 0038 getconstant :M 0040 opt_send_without_block <calldata!mid:name, argc:0, ARGS_SIMPLE> 0042 newarray 2 0044 leave ( 7)[Br] ``` Seems to only happen on trunk and not to be an issue on 4.0.x, 3.4.x, 3.3.x. https://godbolt.org/z/TG9h1j37h Seems to have started with commit:f4813a34c2 "compile.c: statically resolve `swap` instructions when possible" as its parent commit doesn't have this issue. CC: @byroot -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126832] [Ruby Feature#22376] Undefine the allocator for Class
by jhawthorn (John Hawthorn) 22 Sep '26

22 Sep '26

Issue #22376 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #22376: Undefine the allocator for Class https://bugs.ruby-lang.org/issues/22376 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- Uninitialized classes, created by `Class.allocate`, are a recurring source of bugs (most recently #22341). Every place that inspects a class's superclass chain has to check whether the class has been initialized, and it's easy to forget one. I'd like to propose that we forbid Class.allocate, as we already do for several other core types (Proc, Method, UnboundMethod, Binding). To do this we: * Undefine the allocator for Class (`rb_undef_alloc_func`) * Replace `Class#initialize` with a Class.new singleton method that allocates and initializes in one step. * Define `Class#dup` and `Class#clone` so that copying a class still works `Class` can't be subclassed, so I don't think we need to worry about calling initialize. The only place I found `Class.allocate` via `gem-codesearch` were copies of ruby/spec, so I don't think forbidding that will cause problems. Before: ```ruby klass = Class.allocate Class.new(klass) # 'Class#initialize': can't inherit uninitialized class (TypeError) klass.superclass # 'Class#superclass': uninitialized class (TypeError) ``` After: ```ruby Class.allocate # undefined method 'allocate' for class Class (NoMethodError) Class.instance_method(:allocate).bind_call(Class) # 'Class#allocate': allocator undefined for Class (TypeError) ``` PR: https://github.com/ruby/ruby/pull/18964 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126831] [Ruby Bug#22375] `Time.new(String)` can disagree with itself about the date
by rwstauner (Randy Stauner) 22 Sep '26

22 Sep '26

Issue #22375 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22375: `Time.new(String)` can disagree with itself about the date https://bugs.ruby-lang.org/issues/22375 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Time.new("2026-02-30T00:00:00Z")` returns a `Time` object that is internally inconsistent. It shows as Feb 30 or Mar 2 depending on what methods are called: ```ruby t = Time.new("2026-02-30T00:00:00Z") # => 2026-02-30 00:00:00 UTC t.mon # => 2 t.day # => 30 (February 30 is invalid) t.to_i # => 1772409600 Time.utc(2026, 3, 2).to_i # => 1772409600 # (Mar 2 gives same #to_i result) t == Time.utc(2026, 3, 2) # => true t + 0 # => 2026-03-02 00:00:00 UTC # plus zero normalizes t # => 2026-02-30 00:00:00 UTC # still invalid t.to_a # => [0, 0, 0, 2, 3, 2026, 1, 61, false, "UTC"] # to_a shows Mar 2 t # => 2026-03-02 00:00:00 UTC # the to_a call appears to have normalized the object ``` The numeric constructor normalizes `Time.new(2026, 2, 30)` to March 2. A string with an offset other than Z (`+02:00`) also normalizes: ```ruby require "time" Time.new("2026-02-30T00:00:00+02:00") # => 2026-03-02 00:00:00 +0200 ``` This has been the behavior since at least Ruby 3.3.0. However, since [commit `77d0d22b`](https://github.com/ruby/ruby/commit/77d0d22b59e175a3f5ad64e53c0eaa7aa11eafcd) (2026-06-22), `Time.iso8601`, `Time.rfc3339`, and `Time.xmlschema` all parse by calling `Time.new(string)` instead of building from `Time.utc(y, m, d, ...)`. So they now inherit this behavior: ```ruby require "time" Time.iso8601("2026-02-30T00:00:00.000000000Z").iso8601(9) # => "2026-02-30T00:00:00.000000000Z" ``` Currently the test suite has a test that raises ArgumentError for an invalid month but we don't appear to have tests for invalid days. I think we should add a test for this case and fix Time.new(string) to normalize consistently. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125979] [Ruby Bug#22188] Debug symbols missing when compiled with GCC LTO
by rwstauner (Randy Stauner) 22 Sep '26

22 Sep '26

Issue #22188 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22188: Debug symbols missing when compiled with GCC LTO https://bugs.ruby-lang.org/issues/22188 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When compiling with LTO (the XCFLAGS and XLDFLAGS below) RUBY_CRASH_REPORT does not resolve symbols. ( export optflags="-O3" cflags="-fno-omit-frame-pointer" export XCFLAGS="-flto=auto -ffat-lto-objects -Werror=lto-type-mismatch" export XLDFLAGS="-flto=auto -ffat-lto-objects" ./configure --disable-install-doc --disable-shared make -j miniruby ) Simple crash simulation: ./miniruby -e 'Process.kill("SEGV", $$)' On master the output includes: -- C level backtrace information ------------------------------------------- /src/miniruby(0x5608c71bafdd) [0x5608c71bafdd] /src/miniruby(0x5608c71c6f46) [0x5608c71c6f46] /src/miniruby(0x5608c6f31370) [0x5608c6f31370] /src/miniruby(0x5608c70e3150) [0x5608c70e3150] /usr/lib/libc.so.6(0x7f62122ac2d0) [0x7f62122ac2d0] /usr/lib/libc.so.6(kill+0xb) [0x7f62122ac4db] /src/miniruby(0x5608c70e1a65) [0x5608c70e1a65] /src/miniruby(0x5608c7189d1e) [0x5608c7189d1e] /src/miniruby(0x5608c718dea7) [0x5608c718dea7] /src/miniruby(0x5608c719417e) [0x5608c719417e] /src/miniruby(0x5608c71b793c) [0x5608c71b793c] /src/miniruby(0x5608c6f3d13c) [0x5608c6f3d13c] /src/miniruby(0x5608c6f42321) [0x5608c6f42321] /src/miniruby(0x5608c6e4f9b3) [0x5608c6e4f9b3] /usr/lib/libc.so.6(0x7f62122956c1) [0x7f62122956c1] /usr/lib/libc.so.6(__libc_start_main+0x89) [0x7f62122957f9] [0x5608c6e4f9f5] With a tiny change to fall back to symtab (even after parsing DWARF) we can get (empty lines added for comparison with next block): -- C level backtrace information ------------------------------------------- /src/miniruby(rb_print_backtrace+0x1d) [0x55f6397aafdd] /src/vm_dump.c:1111 /src/miniruby(rb_vm_bugreport+0xa26) [0x55f6397b6f46] /src/vm_dump.c:1473 /src/miniruby(rb_bug_for_fatal_signal+0x110) [0x55f639521370] /src/error.c:1140 /src/miniruby(sigsegv+0x50) [0x55f6396d3150] /src/signal.c:948 /usr/lib/libc.so.6(0x7f991555d2d0) [0x7f991555d2d0] /usr/lib/libc.so.6(kill+0xb) [0x7f991555d4db] /src/miniruby(rb_f_kill+0x205) [0x55f6396d1a65] /src/signal.c:487 /src/miniruby(vm_call_cfunc_with_frame_+0xfe) [0x55f639779d1e] /src/vm_insnhelper.c:3821 /src/miniruby(vm_sendish.constprop.0+0xb7) [0x55f63977dea7] /src/vm_insnhelper.c:6056 /src/miniruby(vm_exec_core.lto_priv.0+0x6e) [0x55f63978417e] /src/insns.def:909 /src/miniruby(rb_vm_exec+0xec) [0x55f6397a793c] /src/vm.c:2825 /src/miniruby(rb_ec_exec_node+0xac) [0x55f63952d13c] /src/eval.c:284 /src/miniruby(ruby_run_node+0x61) [0x55f639532321] /src/eval.c:322 /src/miniruby(main+0x63) [0x55f63943f9b3] ./main.c:42 PR: https://github.com/ruby/ruby/pull/17743 Currently the code in addr2line.c has a stub: case DW_FORM_ref_addr: goto finish; /* not supported yet */ If we add support for that we can get better names and inlined frames (empty lines added for comparison with previous block): -- C level backtrace information ------------------------------------------- /src/miniruby(rb_print_backtrace+0x1d) [0x55cd045f81dd] /src/vm_dump.c:1111 /src/miniruby(fprintf+0x0) [0x55cd04604146] /src/vm_dump.c:1473 /src/miniruby(rb_vm_bugreport) /src/vm_dump.c:1476 /src/miniruby(rb_bug_for_fatal_signal+0x110) [0x55cd0436e370] /src/error.c:1140 /src/miniruby(sigsegv+0x50) [0x55cd04520150] /src/signal.c:948 /usr/lib/libc.so.6(0x7f9ef85522d0) [0x7f9ef85522d0] /usr/lib/libc.so.6(kill+0xb) [0x7f9ef85524db] /src/miniruby(rb_f_kill+0x205) [0x55cd0451ea65] /src/signal.c:487 /src/miniruby(vm_call_cfunc_with_frame_+0xfe) [0x55cd045c6f1e] /src/vm_insnhelper.c:3821 /src/miniruby(vm_sendish+0xb7) [0x55cd045cb0a7] /src/vm_insnhelper.c:6056 /src/miniruby(vm_exec_core+0x6e) [0x55cd045d137e] /src/insns.def:909 /src/miniruby(vm_exec_loop+0x16) [0x55cd045f4b3c] /src/vm.c:2825 /src/miniruby(rb_vm_exec) /src/vm.c:2801 /src/miniruby(rb_ec_exec_node+0xac) [0x55cd0437a13c] /src/eval.c:284 /src/miniruby(ruby_run_node+0x61) [0x55cd0437f321] /src/eval.c:322 /src/miniruby(rb_main+0x22) [0x55cd0428c9b3] ./main.c:42 /src/miniruby(main) ./main.c:62 /usr/lib/libc.so.6(0x7f9ef853b6c1) [0x7f9ef853b6c1] /usr/lib/libc.so.6(__libc_start_main+0x89) [0x7f9ef853b7f9] /src/miniruby(_start+0x25) [0x55cd0428c9f5] ./main.c:63 PR: https://github.com/ruby/ruby/pull/17744 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126826] [Ruby Bug#22341] Class#superclass can crash the interpreter in debug build
by tekknolagi (Maxwell Bernstein) 22 Sep '26

22 Sep '26

Issue #22341 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Bug #22341: Class#superclass can crash the interpreter in debug build https://bugs.ruby-lang.org/issues/22341 * Author: tekknolagi (Maxwell Bernstein) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- While implementing this in ZJIT, @nirvdrum reported, and I investigated, a potential interpreter crash: module M; end C = Class.allocate C.include M C.superclass In a debug build, this crashes: plum% ./build-dev/miniruby crash.rb ../object.c:2398: Assertion Failed: rb_class_superclass:!RCLASS_SUPER(klass) ruby 4.1.0dev (2026-09-22T14:09:58Z mb-class-superclass 05c0248e3a) +PRISM [arm64-darwin25] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 l:y b:0001 r:0x0 CFUNC :superclass c:0002 p:0027 s:0006 e:000005 l:n b:---- r:0x0 EVAL crash.rb:4 [FINISH] c:0001 p:0000 s:0003 E:001fc8 l:y b:---- r:0x0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- crash.rb:4:in '<main>' crash.rb:4:in 'superclass' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_print_backtrace+0x24) [0x100b210c4] /Users/emacs/Documents/code/ruby/build-dev/../vm_dump.c:1113 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_print_backtrace) (null):0 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_vm_bugreport+0x3ac) [0x100b21490] /Users/emacs/Documents/code/ruby/build-dev/../vm_dump.c:1479 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_assert_failure_detail+0x138) [0x10079c6b4] /Users/emacs/Documents/code/ruby/build-dev/../error.c:1258 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_assert_failure_detail+0x0) [0x10079c57c] /Users/emacs/Documents/code/ruby/build-dev/../error.c:1234 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_assert_failure) (null):0 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_class_superclass+0x254) [0x1008b1d18] /Users/emacs/Documents/code/ruby/build-dev/../object.c:2398 /Users/emacs/Documents/code/ruby/build-dev/miniruby(ractor_safe_call_cfunc_0+0x30) [0x100b0a8bc] ../vm_insnhelper.c:3720 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc_with_frame_+0x290) [0x100af8900] ../vm_insnhelper.c:3904 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc_with_frame+0x6c) [0x100af8bfc] ../vm_insnhelper.c:3950 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc_other+0x38c) [0x100af84d0] ../vm_insnhelper.c:3976 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_cfunc+0x128) [0x100aede50] ../vm_insnhelper.c:4058 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_method_each_type+0x200) [0x100aecf90] ../vm_insnhelper.c:4896 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_method+0xe8) [0x100aecba4] ../vm_insnhelper.c:5022 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_call_general+0x28) [0x100a9b1f8] ../vm_insnhelper.c:5066 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_sendish+0x708) [0x100ab4424] ../vm_insnhelper.c:6283 /Users/emacs/Documents/code/ruby/build-dev/miniruby(vm_exec_core) ../insns.def:911 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_vm_exec+0x118) [0x100a9c92c] /Users/emacs/Documents/code/ruby/build-dev/../vm.c:2901 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_iseq_eval_main+0x34) [0x100adef20] /Users/emacs/Documents/code/ruby/build-dev/../vm.c:3254 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_ec_exec_node+0x100) [0x1007ac1f8] /Users/emacs/Documents/code/ruby/build-dev/../eval.c:300 /Users/emacs/Documents/code/ruby/build-dev/miniruby(ruby_run_node+0x94) [0x1007ac0ac] /Users/emacs/Documents/code/ruby/build-dev/../eval.c:338 /Users/emacs/Documents/code/ruby/build-dev/miniruby(rb_main+0x40) [0x10067ca2c] /Users/emacs/Documents/code/ruby/build-dev/../main.c:42 /Users/emacs/Documents/code/ruby/build-dev/miniruby(main+0x70) [0x10067c9b8] /Users/emacs/Documents/code/ruby/build-dev/../main.c:62 -- https://bugs.ruby-lang.org/

2 1