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

[ruby-core:126092] [Ruby Bug#22197] Backtraces show methods which do not exist
by Eregon (Benoit Daloze) 24 Jul '26

24 Jul '26

Issue #22197 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22197: Backtraces show methods which do not exist https://bugs.ruby-lang.org/issues/22197 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] * Backport: 3.3: DONTNEED, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby class Parent def original puts caller_locations(0), nil end end class Child < Parent alias_method :alias, :original end Child.new.alias module Original def original puts caller_locations(0) end end class A define_method(:a, Original.instance_method(:original)) end A.new.a ``` gives: ``` $ ruby -v backtrace_alias.rb ruby 4.0.3 (2026-04-21 revision 85ddef263a) +PRISM [arm64-darwin25] backtrace_alias.rb:3:in 'Child#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'A#original' backtrace_alias.rb:23:in '<main>' ``` But this seems clearly incorrect: * there is no `Child#original`, there is only `Parent#original` and `Child#alias`. * there is no `A#original`, there is only `Original#original` and `A#a`. This behavior exists since Ruby 3.4 which added the module name in backtraces (#19117). So the issue is that backtraces show the "original method name from the definition" with the "method owner of the actually-called method". It should be consistent to avoid showing methods which don't exist. And it should be the original method from the definition, because we show the file and line of that, so we should also show the original name (already the case) and the original module (not the case yet, the bug). FWIW TruffleRuby already behaves like that: ``` $ truffleruby 34.0.1 (2026-04-26), like ruby 3.4.9, Oracle GraalVM Native [arm64-darwin23] backtrace_alias.rb:3:in 'Parent#original' backtrace_alias.rb:11:in '<main>' backtrace_alias.rb:15:in 'Original#original' backtrace_alias.rb:23:in '<main>' ``` In #19117 there was some discussion about this, notably: https://bugs.ruby-lang.org/issues/19117#note-17 @byroot > My suggestion is for the owner. Simply put because it matches the path and other existing method representations. But actually the owner isn't that, what is described here is the original module of the method definition, same as the expected from this issue. https://bugs.ruby-lang.org/issues/19117#note-18 @eregon > It must be the owner, anything else would be very confusing. > I believe nobody wants String#then (there is no such method), they want to see Kernel#then. Where I was wrong about owner being the only thing. I was also expressing we should show where the method is defined, but I overlooked the "originally" part (aliases, define_method, etc). Also CC @mame who implemented the change. I think this is worth fixing for Ruby 4.1 (not sure if worth backporting). -- https://bugs.ruby-lang.org/

2 3

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 24 Jul '26

24 Jul '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126154] [Ruby Bug#11438] native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32
by hsbt (Hiroshi SHIBATA) 24 Jul '26

24 Jul '26

Issue #11438 has been updated by hsbt (Hiroshi SHIBATA). https://github.com/ruby/ruby/pull/18054 ---------------------------------------- Bug #11438: native_thread_init_stack() get machine.stack_start unequal to thread's stack start address, x86 win32 https://bugs.ruby-lang.org/issues/11438#change-118198 * Author: rickerliang (l ly) * Status: Assigned * Assignee: windows * ruby -v: 2.2.2 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- In function native_thread_init_stack() use VirtualQuery to get thread's stack start address.But some situation(ruby embbed in other application and initial it on the fly),native_thread_init_stack() will be called at low stack address and VirtualQuery return memory info BaseAddress + RegionSize < thread stack base(teb.StackBase). In this situation,subsequently call stack_check() at high stack address will cause stack_overflow exception,because esp > machine.stack_start: (teb.StackLimit < machine.stack_start < esp < teb.StackBase) but actually it is not stack overflow at this time. Use teb.StackBase instead of VirtualQuery get thread stack base is a more reliable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126138] [Ruby Misc#22206] Replace `tool/update-deps` with source-based dependency generation
by nobu (Nobuyoshi Nakada) 24 Jul '26

24 Jul '26

Issue #22206 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #22206: Replace `tool/update-deps` with source-based dependency generation https://bugs.ruby-lang.org/issues/22206 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose replacing `tool/update-deps` with `tool/mkdepend.rb`, a dependency generator written in Ruby that scans the source files directly. The complete dependency lists would be generated into the build directory instead of being committed. The repository would retain only the source mappings and manual rules needed to determine which source builds each object. ## Problems with `tool/update-deps` `tool/update-deps` has several practical problems. 1. It depends on GNU make and GCC-specific output. It obtains build information from `make -p` and requires GCC’s `-save-temps=obj` option. This also means that `ccache` and similar compiler wrappers must be disabled. The dependency update procedure therefore cannot run directly on every platform supported by Ruby. 2. Updating dependencies is expensive. The current procedure requires a configured tree and a compiler build before dependencies can be inspected. A dependency-only change should not require compiling Ruby and its extensions first. 3. The generated `depend` files are very large. Most of their contents are mechanically generated header dependencies. They make reviews noisy, cause large diffs when a commonly included header changes, and are easy to leave stale. In the prototype, approximately 70,000 generated lines can be removed from 98 `depend` files. 4. The checked-in files duplicate information available from the sources. Most header dependencies can be obtained by recursively following `#include` directives. Only the object-to-source mappings and a small number of rules for generated or substituted sources need to be recorded explicitly. ## Proposal Add `tool/mkdepend.rb` and use it instead of `tool/update-deps`. `tool/mkdepend.rb` scans C and parser sources recursively, resolves quoted and angle-bracket includes using Ruby’s source layout, and writes Make dependency rules. It does not require a configured build, GNU make, or a C compiler, and it runs with Ruby 3.1. Unknown preprocessor conditions are handled conservatively by scanning both branches. Source-specific `define` and `undef` declarations are available when one branch must be selected. Small declarations in `depend` files also describe generated source templates, logical dependencies, and macro-based include names that cannot be inferred from ordinary file lookup. Targets declared in the manual part of each `depend` file are treated as generated files. This avoids maintaining a second list of generated files. ### Repository and build directory layout The sections between these markers remain in the repository: ```make # AUTOGENERATED DEPENDENCIES START array.$(OBJEXT): {$(VPATH)}array.c # AUTOGENERATED DEPENDENCIES END ``` They contain only the minimal object-to-source mappings. Manual Make rules outside the section remain unchanged. When a base Ruby is available, `configure` expands these mappings and writes the complete dependency files under `.deps` in the build directory. The generated Makefile includes those files. This applies to out-of-tree builds, GNU make builds, and Windows NMAKE builds. Release snapshots expand the dependencies before packaging. A release tarball can therefore still be configured without a base Ruby and use the dependency files included in the source tree. ### Commands The proposed commands are: ```sh # Check the committed source mappings. ruby tool/mkdepend.rb --scope=all --sources --check # Update the committed source mappings. ruby tool/mkdepend.rb --scope=all --sources --inplace # Generate complete dependencies. ruby tool/mkdepend.rb --scope=all --output=.deps ``` The existing `make check-depends` and `make fix-depends` targets invoke these operations, so contributors do not need to remember the command-line details. ## Benefits - Dependency generation works without GNU make or GCC. - It runs before the main build and does not require compiler output. - Complete dependencies are generated for the current source tree on every build instead of being kept as a large generated snapshot in Git. - Dependency updates become small and reviewable, usually changing only an object-to-source mapping or an explicit declaration. - The same generator can produce paths appropriate for GNU make and NMAKE. - Out-of-tree builds keep generated dependency data out of the source tree. ## Limitations This is a dependency scanner, not a complete C preprocessor. Conditions that cannot be decided safely are scanned in both directions, which may produce extra dependencies but should not omit required ones. The scanner also cannot infer that a newly added C file should become a build object when there is no object rule for it. That information belongs to the Makefile or the minimal source mapping and must still be added explicitly. ## Prototype A working implementation is available at: <https://github.com/nobu/ruby/tree/mkdepend> It includes the source scanner, dependency declarations, configure and NMAKE integration, snapshot handling, dependency checks, and tests for Ruby 3.1. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124418] [Ruby Feature#21826] Deprecating RubyVM::AbstractSyntaxTree
by Eregon (Benoit Daloze) 23 Jul '26

23 Jul '26

Issue #21826 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21826: Deprecating RubyVM::AbstractSyntaxTree https://bugs.ruby-lang.org/issues/21826 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I think it is time to deprecate `RubyVM::AbstractSyntaxTree`. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/) so it's clear the official Ruby parsing API is the Prism API. `RubyVM::AbstractSyntaxTree` is CRuby-specific and does not work on any other Ruby implementation, the API is unstable, inconvenient, etc: > This module is experimental and its API is not stable, therefore it > might change without notice. As examples, the order of children nodes is > not guaranteed, the number of children nodes might change, there is no > way to access children nodes by name, etc. Because it's under `RubyVM`, it also has the following documented caveats: > This module is for very limited purposes, such as debugging, prototyping, and research. > Normal users must not use it. This module is not portable between Ruby implementations. Given these caveats I think it could possibly be fair enough to remove it without deprecation, however I see no urgency to remove it straight away so I think having it deprecated for one release is nicer for the few gems using it. The advantages of deprecating it are: * Make it clear that this API should not be used in new code * Encourage the few usages to migrate to the Prism API, which is stable, officially supported, designed with many people to be usable and convenient for every parsing/tooling usage, etc. * Improve portability of Ruby code between Ruby implementations So, let's deprecate `RubyVM::AbstractSyntaxTree` in 4.1, and remove it in 4.2? -- https://bugs.ruby-lang.org/

4 5

[ruby-core:126149] [Ruby Bug#22209] IO#set_encoding is ignoring the :newline keyword argument when given Encoding positional argument
by andrykonchin (Andrew Konchin) 23 Jul '26

23 Jul '26

Issue #22209 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #22209: IO#set_encoding is ignoring the :newline keyword argument when given Encoding positional argument https://bugs.ruby-lang.org/issues/22209 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ### Behavioral Discrepancy of the `:newline` Option with Single `Encoding` Objects When calling `IO#set_encoding` with a single positional argument, the `:newline` option (e.g., `newline: :universal`) is parsed and applied only when the encoding is passed as a `String`. When passed as an `Encoding` object, the option is silently ignored and no validation or conversion is performed. #### 1. Passing Encoding as a String (option applied correctly) When the encoding is specified as a `String`, the `:newline` option is parsed and correctly normalizes CRLF line endings to LF: ```ruby data = "line1\r\nline2\r\n" File.write("1.txt", data) File.open("1.txt") do |f| f.set_encoding("utf-8", newline: :universal) p f.read # => "line1\nline2\n" end ``` #### 2. Passing Encoding as an Encoding Object (option ignored) When the encoding is specified as an Encoding object, the `:newline` option is ignored, and the CRLF line endings remain unmodified: ```ruby data = "line1\r\nline2\r\n" File.write("1.txt", data) File.open("1.txt") do |f| f.set_encoding(Encoding::UTF_8, newline: :universal) p f.read # => "line1\r\nline2\r\n" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126146] [Ruby Bug#22208] Install compile seg fault ruby-3.2.4 on openSuSE Leap 16
by wmotycka (Wayne Motycka) 23 Jul '26

23 Jul '26

Issue #22208 has been reported by wmotycka (Wayne Motycka). ---------------------------------------- Bug #22208: Install compile seg fault ruby-3.2.4 on openSuSE Leap 16 https://bugs.ruby-lang.org/issues/22208 * Author: wmotycka (Wayne Motycka) * Status: Open * ruby -v: 3.2.4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Platform: NAME="openSUSE Leap" VERSION="16.0" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="16.0" PRETTY_NAME="openSUSE Leap 16.0" RVM version: rvm 1.29.12 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io] I'm using RVM to install ruby-3.2.4 on this system. A seg fault during the compilation of tools/transform_mjit_header.rb with the indicted line number is doing a string gsub! operation. I ran RVM --trace to garner the attached rvm_3.2.4_install_trace.out. Also tried installing ruby-3.2.9 through RVM and same result (seg fault) from the same tools/transform_mjit_header.rb script. ---Files-------------------------------- rvm_install_324_make.log (91.7 KB) rvm_3.2.4_install_trace.out (736 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125247] [Ruby Bug#21995] mkmf generates a non-deterministic log file
by gemmaro (Gemma Kosaka) 23 Jul '26

23 Jul '26

Issue #21995 has been reported by gemmaro (Gemma Kosaka). ---------------------------------------- Bug #21995: mkmf generates a non-deterministic log file https://bugs.ruby-lang.org/issues/21995 * Author: gemmaro (Gemma Kosaka) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, When compiling Ruby's C extensions with mkmf, it can generate a `mkmf.log` file with non-deterministic content, especially at the line below: ```txt ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This can be problematic on some distributions/package-managers, since the `mkmf.log` file is included in the files generated by `gem install`. {{collapse(example flow) Note about an example flow where randomized filenames occur: 1. `extconf.rb` has calls to `have_func` 2. `gem install` is run by the user 3. It invokes mkmf to process the `extconf.rb` file 4. The checks fail and print intermediate randomized filenames, which are recorded in `mkmf.log` file 5. `gem install` includes `mkmf.log` in the packaged files 6. When the gem is built/packaged multiple times, a reproducibility problem occurs }} {{collapse(background) As a background, the previously reported/related issues are: * ##15304 * This mentions temporary filenames in the generated Makefile, and they are not reproducible. * The necessity/value of including `Makefile`, `gem_make.out`, and `mkmf.log` files are questioned. * So the [pull request](https://github.com/ruby/rubygems/pull/2481) was created to omit these files when installing gems. * However, deleting these files might break compatibility, so the pull request was closed. * Note: There is an [entry](https://github.com/ruby/rubygems/blob/3e3addb8d222d23ac46ca3b1959b29… about `mkmf.log` in the RubyGems' changelog: > ## 2.2.2 / 2014-02-05 > > ### Bug fixes: > > * [...] > * The `mkmf.log` is now placed next to `gem_make.out` when building extensions. * ##19329 * This points out that `gem install` installs `mkmf.log` file. * It was [transferred](https://github.com/ruby/rubygems/issues/6259) at RubyGems GitHub repository. * There are some issues related to this topic on the GNU Guix channel * For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem [occured](https://codeberg.org/guix/guix/pulls/5166). * There should be other workarounds in the Nix community, apparently. }} To wrap up, I think the followings are desirable: * Conventional file locations should be kept as is on the RubyGems side. * Just deleting these files breaks compatibilities. * These might be helpful when users report issues to gem owners with detailed information. * It is helpful if generated file contents are as reproducible as possible. * In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder. * Luckily, workarounds are possible in distribution package recipes such as deleting these files. * -> the component that generates `mkmf.log` is mkmf, so it might be resolvable by modifying mkmf itself. Thank you, gemmaro. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:126140] [Ruby Misc#22207] Sorting issues in Redmine not allowed when logged out
by p8 (Petrik de Heus) 22 Jul '26

22 Jul '26

Issue #22207 has been reported by p8 (Petrik de Heus). ---------------------------------------- Misc #22207: Sorting issues in Redmine not allowed when logged out https://bugs.ruby-lang.org/issues/22207 * Author: p8 (Petrik de Heus) * Status: Open ---------------------------------------- When I'm logged out sorting on the updated_on isn't allowed. The following page results in a 403: https://bugs.ruby-lang.org/projects/ruby-master/issues?sort=updated_on%3Ade… This doesn't happen on the official Redmine website: https://www.redmine.org/projects/redmine/issues?sort=updated_on%3Adesc%2Cid… -- https://bugs.ruby-lang.org/

2 1

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

22 Jul '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/

2 2