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

[ruby-core:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 10 Jul '26

10 Jul '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125889] [Ruby Feature#22136] `sprintf` shouldn't raise ArgumentError when $DEBUG is set
by byroot (Jean Boussier) 10 Jul '26

10 Jul '26

Issue #22136 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22136: `sprintf` shouldn't raise ArgumentError when $DEBUG is set https://bugs.ruby-lang.org/issues/22136 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Expected behavior If I'm tracking down a problem and suspect an error might be swallowed somewhere, I do run my test case with `RUBYOPT="-d"` (or simply set `$DEBUG = true`. I do expect the program to execute all in the same way than without `-d`, expect for extra output on STDERR. ### Actual behavior If some code happens to call `sprintf` or `String#%` with too many arguments, then it will raise an error and likely break the program, preventing me from simply running the same code but in debug mode. ### Reproduction ``` $ ruby -e 'sprintf("foo", "bar"); p :ok' :ok $ ruby -We 'sprintf("foo", "bar"); p :ok' -e:1: warning: too many arguments for format string :ok $ ruby -dWe 'sprintf("foo", "bar"); p :ok' Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1423 - cannot load such file -- rubygems/defaults/operating_system Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1438 - cannot load such file -- rubygems/defaults/ruby Exception 'ArgumentError' at -e:1 - too many arguments for format string Exception 'RuntimeError' at <internal:ast>:96 - cannot get AST for ISEQ compiled by prism -e:1:in 'Kernel#sprintf': too many arguments for format string (ArgumentError) from -e:1:in '<main>' ``` ### Bug or Feature? I looked around the Ruby codebase, as far as I can tell this is the only method behaving this way (aside from its aliases like `String#%`). So I filed this as a Feature, but really in my opinion it is a bug. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125903] [Ruby Feature#22139] Prohibit `END{}`/`Kernel#at_exit` in non-main Ractor
by ko1 (Koichi Sasada) 10 Jul '26

10 Jul '26

Issue #22139 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22139: Prohibit `END{}`/`Kernel#at_exit` in non-main Ractor https://bugs.ruby-lang.org/issues/22139 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- Let's prohibit `END{}`/`Kernel#at_exit` on non-main Ractor. The current behavior is strange: ```ruby Ractor.new{ at_exit{ p [self, Ractor.current] } } sleep 1 #=> [#<Ractor:#2 t.rb:2 terminated>, #<Ractor:#1 running>] ``` There are some options: 1. prohibit them. Simple. 2. invoke the block at the end of the Ractor. 3. invoke the block at the end of the process on main Ractor. It is similar idea of the current behavior. 2 is rejected clearly by Matz because of the semantic gap with current behavior. 3 is no problem because the block and reachable objects from the block can be inherited to main Ractor. However, to make it simple, now let's prohibit them (1), and revisit if we found the (3) is needed. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123883] [Ruby Feature#21704] Expose rb_process_status_new to C extensions
by noteflakes (Sharon Rosner) 10 Jul '26

10 Jul '26

Issue #21704 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21704: Expose rb_process_status_new to C extensions https://bugs.ruby-lang.org/issues/21704 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_new` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126019] [Ruby Feature#16757] Add intersection to Range
by matz (Yukihiro Matsumoto) 10 Jul '26

10 Jul '26

Issue #16757 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed Closing this issue. We have accepted `Range#clamp` (#22175), which covers the main use case here: restricting a range to given bounds. For overlapping ranges it gives the same result as an intersection would. I do not want to add a general `Range#intersection` (or `Range#&`). It raises semantic questions with no obviously right answer, such as what to return for disjoint ranges (`nil`, an empty range, or an exception). More fundamentally, it frames Range as a set-like collection, which invites `Range#union` next, and union of two ranges cannot be defined in general because the result may be discontiguous. I prefer to keep Range out of set algebra. Matz. ---------------------------------------- Feature #16757: Add intersection to Range https://bugs.ruby-lang.org/issues/16757#change-117998 * Author: stuyam (Stuart Yamartino) * Status: Closed ---------------------------------------- It would be great if there was a way to do an intersection with ranges. I wrote a method recently to solve this but it gets complicated and doesn't solve for all edge cases. The example I was using it for was getting the intersection of two date ranges. I was using it to calculate pricing discounts for overlapping dates for a reservation system. I would propose something like: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)) & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)) => Wed, 15 Apr 2020..Mon, 20 Apr 2020 ``` There are a handful of array methods that you can just convert a range to and do on an arrays rather than the ranges themselves, like so: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)).to_a & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)).to_a => [Wed, 15 Apr 2020, Thu, 16 Apr 2020, Fri, 17 Apr 2020, Sat, 18 Apr 2020, Sun, 19 Apr 2020, Mon, 20 Apr 2020] ``` There are a few issues with this however: 1. Performance: creating the ranges into arrays and doing array calculations can me slower based on the span of the range. 2. Returning a range: if you want to go back to a range, you need to convert the resulting array back to a range, which involves min and maxing the array and handling nil edge cases. 3. Infinite ranges: Now that there are endless and beginless ranges added in ruby 2.6 and 2.7 respectively, you can not convert an infinite range to an array and therefore can't do an intersection without more complex logic. I think the added infinite range support makes it a good reason to add range intersections since that is a feature you can't accomplish with just an array. It looks like there was an [Array#intersection alias](https://bugs.ruby-lang.org/issues/16155) added for Array#& recently. I would propose Range#& and Range#intersection to have parity with Array and Set methods. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125920] [Ruby Feature#22175] Add `Range#clamp`
by nobu (Nobuyoshi Nakada) 10 Jul '26

10 Jul '26

Issue #22175 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22175: Add `Range#clamp` https://bugs.ruby-lang.org/issues/22175 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I would like to propose `Range#clamp`, which returns a new `Range` whose begin and end values are clamped to the given bounds. Proposed call-seq: ```ruby range.clamp(min, max) -> range range.clamp(bounds) -> range ``` This is a range counterpart of `Comparable#clamp`. While `Comparable#clamp` clamps a single value, `Range#clamp` clamps both endpoints of a range. Examples: ```ruby (1..10).clamp(3, 7) #=> 3..7 (1...10).clamp(3, 7) #=> 3..7 (1...10).clamp(3, 10) #=> 3...10 (0...).clamp(0, 10) #=> 0..10 (1..10).clamp(3..7) #=> 3..7 (1..10).clamp(3...7) #=> 3...7 (1..5).clamp(3...7) #=> 3..5 ``` `clamp(min, max)` behaves like clamping by an inclusive range `min..max`. If an exclusive upper bound is needed, a range argument can be used: ```ruby (1..10).clamp(3...7) #=> 3...7 ``` Beginless and endless ranges are also supported: ```ruby (..10).clamp(3, 7) #=> 3..7 (0...).clamp(0, 10) #=> 0..10 (1..10).clamp(..7) #=> 1..7 (1..10).clamp(...7) #=> 1...7 (1..10).clamp(3..) #=> 3..10 ``` If the receiver is entirely outside the clamping bounds, the returned range is empty: ```ruby (1..10).clamp(20..30) #=> 20...20 (1..10).clamp(-10..0) #=> 0...0 (1..).clamp(..0) #=> 0...0 ``` The returned range excludes its end when the returned end value is an excluded end value of either the receiver or the argument range: ```ruby (1...10).clamp(3, 10) #=> 3...10 (1..10).clamp(3...10) #=> 3...10 ``` Otherwise, the returned range includes its end. #### Relation to [Feature #16757] [Feature #16757] proposes `Range#intersection` / `Range#&` as a general operation for intersecting two ranges. `Range#clamp` is closely related, but intentionally narrower. It treats the argument as clamping bounds for the receiver, similar to how `Comparable#clamp` treats its arguments as bounds for one value. For overlapping ranges, `range.clamp(bounds)` often produces the same result as a range intersection. For example: ```ruby (1..10).clamp(3..7) #=> 3..7 ``` However, `clamp` has a bounds-oriented API and naturally supports the two-argument form: ```ruby (1..10).clamp(3, 7) #=> 3..7 ``` Also, when the receiver is outside the bounds, `clamp` returns an empty `Range` at the nearest bound, rather than needing to decide whether a general intersection operation should return `nil`, `[]`, an empty range, or raise: ```ruby (1..10).clamp(20..30) #=> 20...20 ``` So this proposal can be considered either independently, as a range counterpart of `Comparable#clamp`, or as a smaller operation that could coexist with a future `Range#intersection`. #### Motivation It is common to restrict ranges to known boundaries, for example when limiting source locations, pagination windows, numeric domains, date/time windows, or user-provided ranges. Currently this has to be written manually by clamping both endpoints and reconstructing the range while preserving the correct excluded-end behavior. That logic is easy to get subtly wrong, especially with exclusive ranges, beginless/endless ranges, and ranges that become empty after clamping. `Range#clamp` would provide a small, direct API for this operation. #### Notes The method returns a new `Range` instance. The single-argument form accepts a range-like object accepted by Ruby’s range conversion logic. Source checked: [[Feature #16757]: Add intersection to Range](https://bugs.ruby-lang.org/issues/16757). -- https://bugs.ruby-lang.org/

5 7

[ruby-core:125953] [Ruby Feature#22185] Add alignment directives to `Array#pack` and `String#unpack`
by nobu (Nobuyoshi Nakada) 10 Jul '26

10 Jul '26

Issue #22185 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22185: Add alignment directives to `Array#pack` and `String#unpack` https://bugs.ruby-lang.org/issues/22185 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- `Array#pack` and `String#unpack` can express byte skips and absolute positions with `x`, `X`, and `@`, but they do not currently have a direct way to align the current position to a byte boundary or to the ABI alignment of another directive. This makes it awkward to describe binary formats that follow C-like structure layout rules. Users need to calculate padding manually, and the required padding can depend on the platform ABI. I propose adding alignment forms to pack templates. ### Alignment Directive ```ruby [1, 2].pack("C x!4 C") # => "\x01\x00\x00\x00\x02" ``` `x!N` advances to the next `N`-byte boundary, filling with NUL bytes when packing and skipping bytes when unpacking. The alignment can also be specified by another directive: ```ruby [1, 2].pack("C x!i i") ``` Here `x!i` aligns to the native alignment of the `i` directive. This lets templates describe platform-dependent native layouts without spelling out the padding size. ### Alignment Mode For formats that need repeated C-structure-style alignment, add an alignment mode: ```ruby [1, 2].pack("!{C i}") ``` This is equivalent to inserting the necessary alignment before each numeric or pointer directive, for example: ```ruby [1, 2].pack("C x!i i") ``` The alignment mode is intentionally not nested. ### Relative and Absolute Alignment There is also a distinction between relative and absolute alignment when `buffer:` or `offset:` is used. `x!` aligns relative to the starting position of the current pack/unpack operation, while `@!` aligns relative to the beginning of the output or input string: ```ruby buffer = +"z" [1, 2].pack("C x!4 C", buffer: buffer) buffer # => "z\x01\x00\x00\x00\x02" buffer = +"z" [1, 2].pack("C @!4 C", buffer: buffer) buffer # => "z\x01\x00\x00\x02" ``` Similarly for unpacking: ```ruby "z\x01\x00\x00\x00\x02".unpack("C x!4 C", offset: 1) # => [1, 2] "z\x01\x00\x00\x02".unpack("C @!4 C", offset: 1) # => [1, 2] ``` This keeps `x!` useful for templates that describe a sub-layout starting at the given `buffer:`/`offset:` position, while `@!` covers formats whose alignment is based on the absolute position in the whole binary string. ### Caveats The directive-alignment form rejects endian modifiers, since byte order does not affect ABI alignment. For example, `x!i` is meaningful, but `x!i<` should not be accepted as an alignment specifier. The alignment is for the pack/unpack offset, not a guarantee about the native address of the underlying String buffer. Callers that need to pass the buffer to C as a typed pointer must ensure separately that the actual address is suitably aligned. Shared substrings, for example, may start at an arbitrary byte offset. ### Examples A concrete use case is building or reading binary records whose layout is shared with C code. For example, a file format, IPC message, device command buffer, or FFI payload may contain records equivalent to: ```C struct entry { uint8_t tag; uint32_t size; void *data; }; ``` Today, a Ruby template has to spell out the padding manually: ```ruby [tag, size, data].pack("C xxx L J") ``` This is both error-prone and ABI-dependent. The padding after `tag` depends on the native alignment of `uint32_t`, and the next field may depend on pointer alignment. With alignment directives, the template can express the intended layout directly: ```ruby [tag, size, data].pack("!{C L J}") ``` or, when only one boundary is needed: ```ruby [tag, size].pack("C x!L L") ``` One target use case is binary buffers that contain several C-like record types. For example, an IPC or device buffer may store a sequence of records, each with its own layout. It is natural to pack or unpack each record with a separate template at a given `buffer:` or `offset:` position. In that case `x!` is useful for alignment relative to the start of the current record, while `@!` is useful for formats whose alignment is defined relative to the start of the whole buffer. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125756] [Ruby Bug#22112] Backport for IO::Buffer USF issues
by nagachika (Tomoyuki Chikanaga) 10 Jul '26

10 Jul '26

Issue #22112 has been reported by nagachika (Tomoyuki Chikanaga). ---------------------------------------- Bug #22112: Backport for IO::Buffer USF issues https://bugs.ruby-lang.org/issues/22112 * Author: nagachika (Tomoyuki Chikanaga) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The following commits are a series of fixes for IO::Buffer use-after-free issues across multiple methods. Please backport them to the stable branches. - commit:2552db04ddc44349c7b0f5f93aeb0fb02eccb509 (Fix UAF in IO::Buffer#&) - commit:95626e3a9c59cd073221c08ed013ed0f2d655b6f (Fix UAF in IO::Buffer#|) - commit:90ed85f91ed8c9df26efcbdc5e6a1b428be3ef06 (Fix UAF in IO::Buffer#^) - commit:3373fcc2dee7c4560d2c3e4280c549cdb1b5de63 (Fix UAF in IO::Buffer#~) - commit:4bd3e14fc2623414680008c7b1d38f1a3df2877e (Fix UAF in IO::Buffer#and!, IO::Buffer#or!, IO::Buffer#xor!) - commit:2c8002d58302e4fff51484826e1fd706cc2bfb19 (Validate the buffer after argument conversion) - commit:773e0c3a0f2ab2bd235c8d44cad1f999bfe2514b (Validate the buffer after type argument conversion) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125590] [Ruby Bug#22086] Backport Marshal overflow fix
by nobu (Nobuyoshi Nakada) 10 Jul '26

10 Jul '26

Issue #22086 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22086: Backport Marshal overflow fix https://bugs.ruby-lang.org/issues/22086 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- GH-17130 * commit:8ed456afc95ccb23256fe10036cd0d9678ceb245 Marshal.load: Fix buffer overflow at overread * commit:2510dfee2a6aba9e99664b453e2be69e00eb21a6 Marshal.load: Fix integer overflow of length * commit:3f6d6c0373d2cb005f7cf164414cbb531f42d525 Marshal.load: Check bignum sign -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125934] [Ruby Bug#22181] SEGV in branch peephole optimization due to label/insn struct aliasing
by viralpraxis (Iaroslav Kurbatov) 09 Jul '26

09 Jul '26

Issue #22181 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #22181: SEGV in branch peephole optimization due to label/insn struct aliasing https://bugs.ruby-lang.org/issues/22181 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-05T09:21:26Z master fd34f67b18) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Both `iseq_label_data` and `iseq_insn_data` share the same layout prefix; in some cases `iseq_label_data->label_no` might collide with `iseq_insn_data->insn_id` (e.g. when there are many (monotonically increasing) label IDs allocated and one of them collides with `branchif := 74`). An example (generated so that the collision actually happens): ```ruby cat test.rb $g&.call&.to_s [*d, [__dir__].each(&:each), C1.value(/ab/o, &b)].each {} begin ((-243 != qux) ? (1..2) : 8i&.value) => ^([1].select(&:to_s)) rescue ((-243 != qux) ? (1..2) : 8i&.value) => ^([1].select(&:to_s)) end ``` ```shell ~/.rubies/ruby-master/bin/ruby test.rb test.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 4.1.0dev (2026-07-05T09:21:26Z master fd34f67b18) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:0026c0 l:y b:---- r:(nil) DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00005835a2c62129 RBP: 0x00005835de29bce0 RSP: 0x00007ffc8774f2e0 RAX: 0x00005835de3254d8 RBX: 0x000000000000004b RCX: 0x0000000000000001 RDX: 0x00005835de29bca0 RDI: 0x00005835de29b880 RSI: 0x0000000000000000 R8: 0x00005835de29b880 R9: 0x00005835a2de1501 R10: 0x0000000000000002 R11: 0x0000000000000000 R12: 0x0000000000000000 R13: 0x00005835a2e325f4 R14: 0x000071196d162b80 R15: 0x0000000000000001 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- ~/.rubies/ruby-master/bin/ruby(rb_print_backtrace+0x14) [0x5835a29e1a33] $RSRC/ruby/vm_dump.c:1111 ~/.rubies/ruby-master/bin/ruby(rb_vm_bugreport) $RSRC/ruby/vm_dump.c:1473 ~/.rubies/ruby-master/bin/ruby(rb_bug_for_fatal_signal+0x101) [0x5835a2cf1221] $RSRC/ruby/error.c:1140 ~/.rubies/ruby-master/bin/ruby(sigsegv+0x48) [0x5835a2911848] $RSRC/ruby/signal.c:948 /lib/x86_64-linux-gnu/libc.so.6(0x711988645330) [0x711988645330] ~/.rubies/ruby-master/bin/ruby(replace_destination+0x3) [0x5835a2c62129] $RSRC/ruby/compile.c:3127 ~/.rubies/ruby-master/bin/ruby(iseq_peephole_optimize) $RSRC/ruby/compile.c:3720 ~/.rubies/ruby-master/bin/ruby(iseq_optimize+0x1cb) [0x5835a2c63f83] $RSRC/ruby/compile.c:4495 ~/.rubies/ruby-master/bin/ruby(iseq_setup_insn) $RSRC/ruby/compile.c:1622 ~/.rubies/ruby-master/bin/ruby(iseq_setup_insn) $RSRC/ruby/compile.c:1611 ~/.rubies/ruby-master/bin/ruby(pm_iseq_compile_node+0x60) [0x5835a2cb1920] $RSRC/ruby/prism_compile.c:10623 ~/.rubies/ruby-master/bin/ruby(pm_iseq_build+0x184) [0x5835a2848d94] $RSRC/ruby/iseq.c:1133 ~/.rubies/ruby-master/bin/ruby(pm_iseq_new_with_opt_try+0x34) [0x5835a2848f14] $RSRC/ruby/iseq.c:1153 ~/.rubies/ruby-master/bin/ruby(rb_protect+0xfb) [0x5835a27d04db] $RSRC/ruby/eval.c:1135 ~/.rubies/ruby-master/bin/ruby(pm_iseq_new_with_opt+0x4d) [0x5835a28478f3] $RSRC/ruby/iseq.c:1181 ~/.rubies/ruby-master/bin/ruby(pm_iseq_new_main) $RSRC/ruby/iseq.c:1005 ~/.rubies/ruby-master/bin/ruby(process_options+0x1475) [0x5835a2902715] $RSRC/ruby/ruby.c:2700 ~/.rubies/ruby-master/bin/ruby(ruby_process_options+0x15d) [0x5835a290342d] $RSRC/ruby/ruby.c:3258 ~/.rubies/ruby-master/bin/ruby(ruby_options+0xc0) [0x5835a27cf1c0] $RSRC/ruby/eval.c:120 ~/.rubies/ruby-master/bin/ruby(rb_main+0x19) [0x5835a27c969e] $RSRC/ruby/jit.c:632 ~/.rubies/ruby-master/bin/ruby(main) ./main.c:62 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x71198862a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x71198862a28b] ../csu/libc-start.c:360 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x5835a27c96f5] ``` -- https://bugs.ruby-lang.org/

3 3