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

[ruby-core:126167] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by Dan0042 (Daniel DeLorme) 25 Jul '26

25 Jul '26

Issue #17056 has been updated by Dan0042 (Daniel DeLorme). ### 1. Object, block, and Enumerator forms Imho there are two options here a) If block form is supported, the offset is a keyword argument. It was not requested by the OP (also not in my duplicate #19177), but it's more versatile and future-proof. Although it introduces incompatibility due to keyword extension (described below) ```ruby index(object, offset: 0) index(offset: 0){ |element| ... } index(offset: 0) ``` b) If block form is not supported, the offset should be a positional argument, for consistency and duck-typing with String#index It's more limited, and makes it hard to add offset to block form in the future. ```ruby index(object, offset = 0) ``` Overall a) seems better to me, even if not fully consistent with String#index ### 2. Compatibility with searching for a Hash Ah yes, this is the standard problem with [keyword extension](#14183#note-29) What would happen with this code? ```ruby [{ key: 2 }].index(key: 2) ``` Will it now raise "unknown keyword: :key" ? ### 3. Semantics of `Array#rindex` > I think the corresponding Array behavior should be: > > ```ruby > [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 2 > [:a, :b, :a, :b, :a].rindex(:a, offset: -2) # => 2 > [:a, :b, :a, :b, :a].rindex(:a, offset: 100) # => 4 > ``` 100% agree. ### 4. Boundary and conversion behavior > Should `Array#index` and `Array#rindex` follow the corresponding String methods for all of these cases? In general I would say yes, simply because having consistency for this reduces gotchas and footguns. But I'm not sure about this behavior of String: ```ruby "0aaaaaaaaaa9".rindex("a", 999) #=> 10 "0aaaaaaaaaa9".index("a", -999) #=> nil ``` To me, these two results are inconsistent and I feel like the last case should return 1. Should Array#index follow the same pattern or not? ```ruby [:a, :b, :a, :b, :a].index(:a, offset: -100) #=> nil (like String#index) or 0 ? ``` ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-118233 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126166] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by nobu (Nobuyoshi Nakada) 25 Jul '26

25 Jul '26

Issue #17056 has been updated by nobu (Nobuyoshi Nakada). Status changed from Closed to Open I think we should reopen this issue and clarify the API before fixing the implementation. There are several API details that I think need to be decided explicitly. ## Issues to clarify ### 1. Object, block, and Enumerator forms The discussion in #note-7 and #note-8 explicitly considered using an offset with the block form: ```ruby array.index(offset: 10) { |element| ... } ``` However, the reverted implementation only handled `offset:` when an object was given. The following calls raised `ArgumentError`, despite the documented Enumerator signatures: ```ruby array.index(offset: 2) array.index(offset: 2) { |element| ... } array.rindex(offset: -2) array.rindex(offset: -2) { |element| ... } ``` Should all three forms accept `offset:`? ```ruby array.index(object, offset: 2) array.index(offset: 2) { |element| ... } array.index(offset: 2) # => Enumerator ``` The same question applies to `Array#rindex`. Since `Array#find_index` is an alias of `Array#index`, it should have exactly the same behavior. If the block form accepts `offset:`, the Enumerator form should retain the keyword argument so that calling `each` performs the same search. ### 2. Compatibility with searching for a Hash Before this feature, the following searches for the Hash `{ offset: 2 }`: ```ruby [{ offset: 2 }].index(offset: 2) # => 0 ``` If a keyword-only call now means the block/Enumerator form, this behavior changes. Searching for the Hash would still be possible with explicit braces: ```ruby [{ offset: 2 }].index({ offset: 2 }) # => 0 ``` Is this compatibility change acceptable? The same ambiguity exists when a block is given. Previously the keyword-like Hash was the object and the block was ignored with a warning. ### 3. Semantics of `Array#rindex` The reverted implementation did not behave like `String#rindex`. It also documented the signature as `rindex(object, offset: nil)`, but an explicit `nil` was not accepted: ```ruby array.rindex(object, offset: nil) # => TypeError: no implicit conversion of nil into Integer ``` In the implementation, `nil` was only used internally to represent an omitted keyword. Documenting `offset: nil` makes it look like `nil` is an accepted default value. For an Array, `offset: -1` would express the actual default starting position while keeping an explicit `nil` invalid. `String#rindex(pattern, offset)` starts searching backward at `offset`. A non-negative offset is an absolute position. A negative offset is relative to the end. An offset greater than the string length is clamped to the end. For example: ```ruby "ababa".rindex("a", 2) # => 2 "ababa".rindex("a", -2) # => 2 "ababa".rindex("a", 100) # => 4 ``` I think the corresponding Array behavior should be: ```ruby [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 2 [:a, :b, :a, :b, :a].rindex(:a, offset: -2) # => 2 [:a, :b, :a, :b, :a].rindex(:a, offset: 100) # => 4 ``` The reverted implementation instead treated a non-negative offset as the lower bound of a search starting at the end: ```ruby [:a, :b, :a, :b, :a].rindex(:a, offset: 2) # => 4 ``` This makes positive and negative offsets have different meanings and is not consistent with `String#rindex`. Should `Array#rindex` follow `String#rindex` exactly? ### 4. Boundary and conversion behavior Should `Array#index` and `Array#rindex` follow the corresponding String methods for all of these cases? - Negative offsets relative to the end - An offset smaller than `-array.size` - An offset equal to `array.size` - An offset greater than `array.size` - Objects accepted through numeric conversion - Explicit `nil` - Integers too large for the internal index type These should be specified and tested for both forward and backward searches. ## Proposed signatures If the above behavior is intended, the signatures would be: ```ruby index(object, offset: 0) -> integer or nil index(offset: 0) { |element| ... } -> integer or nil index(offset: 0) -> Enumerator find_index(object, offset: 0) -> integer or nil find_index(offset: 0) { |element| ... } -> integer or nil find_index(offset: 0) -> Enumerator rindex(object, offset: -1) -> integer or nil rindex(offset: -1) { |element| ... } -> integer or nil rindex(offset: -1) -> Enumerator ``` The implementation has been reverted. Once these points are agreed, I think we should add specs for the complete behavior before reimplementing it. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-118232 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`
by ioquatix (Samuel Williams) 25 Jul '26

25 Jul '26

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

8 19

[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: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