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

[ruby-core:124267] [Ruby Bug#21786] Net::HTTP::Response#read_body crashes on nil body when response_body_encoding is a String
by karinamendez132＠gmail.com (Karina Mendez) 16 Dec '25

16 Dec '25

Issue #21786 has been reported by karinamendez132(a)gmail.com (Karina Mendez). ---------------------------------------- Bug #21786: Net::HTTP::Response#read_body crashes on nil body when response_body_encoding is a String https://bugs.ruby-lang.org/issues/21786 * Author: karinamendez132(a)gmail.com (Karina Mendez) * Status: Open * ruby -v: ruby 3.2.0p0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When response_body_encoding is set to a String value (e.g., 'UTF-8'), and the HTTP response body is nil due to network failures, read_body attempts to call force_encoding on nil at line 360, raising NoMethodError. The issue occurs because String values fall through to the else branch which calls detect_encoding(@body) without checking if @body is nil. Line 360 should verify @body is not nil before calling force_encoding. Category: lib Target version:current Reproducible script: require 'net/http' # Monkey patch to simulate nil body scenario class Net::HTTP::Response alias_method :original_reading_body, :reading_body def reading_body(sock, reqmethodallowbody) @socket = sock @body_exist = false # Force nil body begin yield self.body # Triggers the bug ensure @socket = nil end end end # Trigger the bug http = Net::HTTP.new('example.com', 443) http.use_ssl = true http.response_body_encoding = 'UTF-8' # String triggers else branch begin http.request(Net::HTTP::Get.new('/')) rescue NoMethodError => e puts "BUG: #{e.message}" puts "Location: #{e.backtrace.first}" end # Expected: Graceful handling # Actual: NoMethodError: undefined method `force_encoding' for nil:NilClass # from lib/net/http/response.rb:360:in `read_body' Suggested fix: In lib/net/http/response.rb line 360, change: @body.force_encoding(enc) if enc to: @body.force_encoding(enc) if enc && @body -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124121] [Ruby Bug#21772] ruby: YJIT has panicked StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760)
by gearoiddc (Gearoid de Cleir) 16 Dec '25

16 Dec '25

Issue #21772 has been reported by gearoiddc (Gearoid de Cleir). ---------------------------------------- Bug #21772: ruby: YJIT has panicked StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760) https://bugs.ruby-lang.org/issues/21772 * Author: gearoiddc (Gearoid de Cleir) * Status: Open * ruby -v: 3.4.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm getting a YJIT has panicked crash in my rails app locally when a part of my application rapidly uses a gem I have "auto_session_timeout". If I patch the gem by changing the symbol to a string the error goes away. ``` ruby module AutoSessionTimeout private def session_expired?(c) c.session[:auto_session_expires_at].<(Time.now) end end ``` to ``` ruby def session_expired?(c) c.session["auto_session_expires_at"].<(Time.now) end ``` I can consistently cause the crash but I can't find a way to reproduce the error in a snipped of code. But it looks like YJIT is keeping the key as a sybmol even though it was converted to a string. def [](key) load_for_read! key = key.to_s if key == "session_id" # <-- crash occurs here id&.public_id else @delegate[key] end end Didn't have the same issue on ruby 3.3 with YJIT. System Configuration Ruby Version: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +YJIT +PRISM [x86_64-linux] Environment: Ubuntu 22.04.5 LTS (x86_64) Backtrace & Logs ``` ruby: YJIT has panicked. More info to follow... thread '<unnamed>' panicked at ./yjit/src/codegen.rs:5018:9: StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760) stack backtrace: 0: __rustc::rust_begin_unwind at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:697:5 1: core::panicking::panic_fmt at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/panicking.rs:75:14 2: yjit::codegen::jit_guard_known_klass at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:5018:9 3: yjit::codegen::gen_equality_specialized at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:3690:9 4: yjit::codegen::gen_opt_eq at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:3753:29 5: yjit::codegen::gen_single_block at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:1382:22 6: yjit::core::gen_block_series_body at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3088:23 7: yjit::core::gen_block_series at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3066:18 8: yjit::core::branch_stub_hit_body at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3604:17 9: yjit::core::branch_stub_hit::{{closure}}::{{closure}} at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3493:36 10: yjit::stats::with_compile_time at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/stats.rs:1084:15 11: yjit::core::branch_stub_hit::{{closure}} at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3493:13 12: std::panicking::catch_unwind::do_call at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:589:40 13: std::panicking::catch_unwind at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:552:19 14: std::panic::catch_unwind at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panic.rs:359:14 15: yjit::cruby::with_vm_lock at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/cruby.rs:688:21 16: yjit::core::branch_stub_hit at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3492:9 17: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. /home/gearoid/.rvm/gems/ruby-3.4.7@7.2.3/gems/actionpack-7.2.3/lib/action_dispatch/request/session.rb:118: [BUG] YJIT: panicked at ./yjit/src/codegen.rs:5018:9: StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760) ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +YJIT +PRISM [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:123576] [Ruby Bug#21654] Set#new calls extra methods compared to previous versions
by tenderlovemaking (Aaron Patterson) 16 Dec '25

16 Dec '25

Issue #21654 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21654: Set#new calls extra methods compared to previous versions https://bugs.ruby-lang.org/issues/21654 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-24T15:50:47Z master a9f24aaccb) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm trying to test Ruby 3.5.0 with our Rails application and we've found that `Set.new` is now causing extra database queries to happen. The changes in d4020dd5faf call "size" on enumerable objects that are passed to the `new` method, and this causes extra "COUNT" queries to happen with ActiveRecord associations. For example: ```ruby Set.new(some_activerecord_association) ``` Previously, the above code would only do one query by iterating over the association. Now it issues two queries, a count query, and then the normal query for results. Since d4020dd5faf is dealing with endless ranges, I would like to narrow the scope from all Enumerable objects to just Ranges. Unfortunately, I noticed we have a test like this: ```ruby assert_raise(ArgumentError) { Set.new(1.upto(Float::INFINITY)) } ``` I'm not sure how we can handle such a case without testing `size`. -- https://bugs.ruby-lang.org/

8 19

[ruby-core:124240] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by Eregon (Benoit Daloze). Right, I thought about that too but forgot to write it. Several gems have already adapted to this feature and their functionality and/or tests might rely on having the extra information, so it's definitely not great to remove this last minute. If https://github.com/ruby/prism/pull/3808 had been merged already we'd make the entire method unusable in Prism, which certainly sounds bad. I think we should do https://github.com/ruby/ruby/pull/15580 ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115726 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124235] [Ruby Feature#6012] Proc#source_location also return the column
by vo.x (Vit Ondruch) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by vo.x (Vit Ondruch). And RSpec were also adjusted to the new behavior AFAICT: https://github.com/rspec/rspec/pull/282/commits/1c20fa80772ca7a1ed0512056ce… ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115721 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124234] [Ruby Feature#6012] Proc#source_location also return the column
by vo.x (Vit Ondruch) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by vo.x (Vit Ondruch). Just FTR, not sure how the revert is supposed to look like, but at least Pry was adjusted for the new behavior: https://github.com/pry/pry/pull/2357 It does not benefit from columns, but I suspect the revert would somehow influenced also the end of method location. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115720 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124232] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-32: > I record the summary of the discussion regarding Matz's decision to revert this for now. The decision was based on a combination of several reasons: Thank you for documenting that. It feels to me like the decision was taken while we were in the middle of discussing https://bugs.ruby-lang.org/issues/21783, where we seem to now have reached an agreement, but the revert decision (and revert PR merged) was taken without any time for me to even reply there. > * Unclear use cases The fact many issues have been filed about this seems to show this is clearly a wanted feature. It has always been useful to find where a method/block is defined. https://rubygems.org/gems/method_source has 700 millions downloads, what other proof do we need? > * Difficulty in changing `Binding#source_location` (#6012#note-24, #21005#note-19) I wasn't aware of these, but I think this is much less needed than on {Proc,Method,UnboundMethod}. Unless I'm missing something, a Binding doesn't always have a properly-defined source location/definition, e.g. for `b = binding`. It has a start line if we consider that to be at the line of the `binding` call, but not really an end line/column. IOW it's not a "scope" unlike a method or block, and seems much less useful. > * Related issues: > * We may need to adjust Proc#source_location's position (#21784). > * We need to discuss column units (bytes vs characters) (#21783). I'm fixing both of these in https://github.com/ruby/ruby/pull/15580. Both issues seem to have rather clear agreements at this point. > * Timing: We can still revert without compatibility issues at this point. The feature has been implemented since 9th January, almost a year ago. It's not been in a proper release yet of course but it has been in multiple previews. I'm not sure if other people have tried it already, but I'm pretty confident a bunch of people are gonna be disappointed if this is removed last minute and it needs another year before it's in a Ruby release. Do we really want to encourage heuristics like https://bugs.ruby-lang.org/issues/20999#note-1 vs a proper a solution by providing the necessary information in `{Method,UnboundMethod,Proc}#source_location`? ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115718 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124229] [Ruby Feature#6012] Proc#source_location also return the column
by mame (Yusuke Endoh) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by mame (Yusuke Endoh). Status changed from Closed to Open I record the summary of the discussion regarding Matz's decision to revert this for now. The decision was based on a combination of several reasons: * Unclear use cases * The description of #6012 lacked a use case. * The use case presented in #21005 was not convincing. * Difficulty in changing `Binding#source_location` (#6012#note-24, #21005#note-19) * `Binding#source_location` still returns `[file, lineno]`. * Implementation issues: It was challenging to preserve the location information of `Kernel#binding` calls within the ISeq. * Compatibility issues: `eval(code, nil, *binding.source_location)` is used in several gems; adding column information would break them. * Related issues: * We may need to adjust Proc#source_location's position (#21784). * We need to discuss column units (bytes vs characters) (#21783). * Timing: We can still revert without compatibility issues at this point. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115715 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124220] [Ruby Feature#6012] Proc#source_location also return the column
by matz (Yukihiro Matsumoto) 15 Dec '25

15 Dec '25

Issue #6012 has been updated by matz (Yukihiro Matsumoto). Although last minute, we will cancel this feature in 4.0 because of design ambiguities such as whether to return column positions in bytes or characters as in #21783. Matz. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115703 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123754] [Ruby Feature#21678] Enumerable#rfind
by kddnewton (Kevin Newton) 15 Dec '25

15 Dec '25

Issue #21678 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21678: Enumerable#rfind https://bugs.ruby-lang.org/issues/21678 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I'd like to introduce `rfind` to enumerable, which would effectively be the same as `reverse_each.find`. I've found myself using this a surprising number of times, and have been surprised at its omission. That means either falling back to `reverse_each` or `rindex`. For context, here are a couple of examples of this in the wild: * [pry](https://github.com/pry/pry/blob/80816f596774d00afdc81a555724b0819bf267… * [bundler](https://github.com/ruby/rubygems/blob/e4fd4ee3fad005fce1dbcbeffd47… * [textbringer](https://github.com/shugo/textbringer/blob/738d318558045efc9d97… -- https://bugs.ruby-lang.org/

5 7