[#120855] [Ruby master Bug#21104] Net::HTTP connections failing in Ruby >= 3.4.0 on macOS with Happy Eyeballs enabled — "mjt58 (Mike Thompson) via ruby-core" <ruby-core@...>

Issue #21104 has been reported by mjt58 (Mike Thompson).

14 messages 2025/02/01

[#120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs — "stanhu (Stan Hu) via ruby-core" <ruby-core@...>

Issue #21111 has been reported by stanhu (Stan Hu).

10 messages 2025/02/03

[#120884] [Ruby master Bug#21115] Etc.getgrgid is not Ractor-safe but is marked as such — "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>

Issue #21115 has been reported by Eregon (Benoit Daloze).

7 messages 2025/02/05

[#120897] [Ruby master Bug#21119] Programs containing `Dir.glob` with a thread executing a CPU-heavy task run very slowly. — "genya0407 (Yusuke Sangenya) via ruby-core" <ruby-core@...>

Issue #21119 has been reported by genya0407 (Yusuke Sangenya).

6 messages 2025/02/06

[#121054] [Ruby master Bug#21139] Prism and parse.y parses `it = it` differently — "tompng (tomoya ishida) via ruby-core" <ruby-core@...>

Issue #21139 has been reported by tompng (tomoya ishida).

19 messages 2025/02/14

[#121060] [Ruby master Feature#21140] Add a method to get the address of certain JIT related functions — "tenderlovemaking (Aaron Patterson) via ruby-core" <ruby-core@...>

Issue #21140 has been reported by tenderlovemaking (Aaron Patterson).

23 messages 2025/02/14

[#121077] [Ruby master Misc#21143] Speficy order of execution const_added vs inherited — "fxn (Xavier Noria) via ruby-core" <ruby-core@...>

Issue #21143 has been reported by fxn (Xavier Noria).

15 messages 2025/02/17

[#121142] [Ruby master Misc#21154] Document or change Module#autoload? — "fxn (Xavier Noria) via ruby-core" <ruby-core@...>

Issue #21154 has been reported by fxn (Xavier Noria).

32 messages 2025/02/23

[#121172] [Ruby master Feature#21157] Comparison operator <> — lpogic via ruby-core <ruby-core@...>

SXNzdWUgIzIxMTU3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGxwb2dpYyAoxYF1a2FzeiBQb21pZXTF

11 messages 2025/02/26

[ruby-core:121119] [Ruby master Misc#20968] `Array#fetch_values` unexpected method name in stack trace

From: "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>
Date: 2025-02-19 01:47:44 UTC
List: ruby-core #121119
Issue #20968 has been updated by jeremyevans0 (Jeremy Evans).


My thinking is inline with @Eregon 's.  It's significantly more work to try to modify the backtraces to omit `<internal:` entries.  Ultimately, I think that hiding such entries results in less helpful information.

If we could show the file and line for C functions, that would be useful for debugging. I assume the only reason we don't is that doing so is not feasible.

Note that even if we hide the `<internal:` methods, you still have the same issue for any method that is defined in C and calls another C or Ruby method in a way that pushes a VM frame:

```
$ ruby -e "Class.new.new(1)"
-e:1:in `initialize': wrong number of arguments (given 1, expected 0) (ArgumentError)

Class.new.new(1)
              ^
        from -e:1:in `new'
        from -e:1:in `<main>'
```

Note that I never overrode `initialize`. I am calling `new`, but `initialize` is showing up in the backtrace even though both `new` and `initialize` are defined in C. The internal reason for this is because `Class.new` uses `rb_funcallv_kw` to call `Obejct#initialize`, which pushes a VM frame.

That being said, if we do want to change behavior of this only for `<internal:` entries, the `Primitive.attr! :c_trace` approach mentioned by @byroot seems preferable to modifying the backtrace internals.  Should we just add that to all `<internal:` methods that call other methods?

----------------------------------------
Misc #20968: `Array#fetch_values` unexpected method name in stack trace
https://bugs.ruby-lang.org/issues/20968#change-112041

* Author: koic (Koichi ITO)
* Status: Open
----------------------------------------

It seems that the current Ruby implementation is displaying unexpected method name in stack trace.

## Expected

Similar to `Hash#fetch_values`, the method name `Array#fetch_values` is expected to be displayed in the stack trace.

```console
$ ruby -e '{k: 42}.fetch_values(:unknown)'
-e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError)
        from -e:1:in '<main>'

$ ruby -e '[1].fetch_values(42)'
-e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError)
        from -e:1:in '<main>'
```


## Actual

The stack trace displays the `Array#fetch` method, which user is not aware of, along with the `<internal.array>` stack trace.

```console
$ ruby -e '[1].fetch_values(42)'
<internal:array>:211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError)
        from <internal:array>:211:in 'block in Array#fetch_values'
        from <internal:array>:211:in 'Array#map!'
        from <internal:array>:211:in 'Array#fetch_values'
        from -e:1:in '<main>'
```


It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/


In This Thread