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

[ruby-core:114315] [Ruby master Bug#19789] YJIT + rustc 1.71.0 is broken with macOS
by hsbt (Hiroshi SHIBATA) 12 Aug '23

12 Aug '23

Issue #19789 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19789: YJIT + rustc 1.71.0 is broken with macOS https://bugs.ruby-lang.org/issues/19789 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Assignee: yjit * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I got some segmentation fault on macOS. ``` 1) Failure: TestVMDump#test_darwin_invalid_call [/Users/hsbt/Documents/github.com/ruby/ruby/test/ruby/test_vm_dump.rb:11]: pid 35071 exit 1 | -e:1: [BUG] Bus Error at 0x0000000000000001 | ruby 3.3.0dev (2023-07-30T06:13:58Z master b5c74d5488) [arm64-darwin23] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | -- Control frame information ----------------------------------------------- | c:0003 p:---- s:0010 e:000009 CFUNC :call | c:0002 p:0015 s:0006 e:000005 EVAL -e:1 [FINISH] | c:0001 p:0000 s:0003 E:000a30 DUMMY [FINISH] | | -- Ruby level backtrace information ---------------------------------------- | -e:1:in `<main>' | -e:1:in `call' | | -- Threading information --------------------------------------------------- | Total ractor count: 1 | Ruby thread count for this ractor: 1 | | -- Machine register context ------------------------------------------------ | x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 | x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x0000000000000000 | x6: 0x0000000000000000 x7: 0x0000000000000000 x18: 0x0000000000000000 | x19: 0x0000000000000000 x20: 0x000000016faadf40 x21: 0x000000016faadf40 | x22: 0x000000016faadec0 x23: 0x0000600001256eb0 x24: 0x000000016faadc70 | x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 | x28: 0x0000000140e04f20 lr: 0x000000019b211050 fp: 0x000000016faadd30 | sp: 0x000000016faadd30 | | -- C level backtrace information ------------------------------------------- | 1360: Abbrev Number 707 not found .. ``` I filed it and other failures to https://gist.github.com/hsbt/ea3e52d9fb52aed58d25caf839eae5ff @katei found this issue caused by YJIT and rustc 1.71.0. It's not happend with ``` ../ruby/configure -C --disable-install-doc --with-openssl-dir=/opt/homebrew/opt/openssl(a)1.1 --with-readline-dir=/opt/homebrew/opt/readline --with-libyaml-dir=/opt/homebrew/opt/libyaml RUSTC='rustc +1.70.0' ``` But `RUSTC='rustc +1.71.0'` is failed with same error on macOS Sonoma(beta) and Ventura. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:114328] [Ruby master Bug#19793] Segmentation fault with large arrays
by sczimmer (Scott Zimmermann) 12 Aug '23

12 Aug '23

Issue #19793 has been reported by sczimmer (Scott Zimmermann). ---------------------------------------- Bug #19793: Segmentation fault with large arrays https://bugs.ruby-lang.org/issues/19793 * Author: sczimmer (Scott Zimmermann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I was doing ruby koans to learn ruby and I got a segmentation fault when it gets to the part where it uses `Symbol.all_symbols`. I realized it happens with any large Array, but I cannot reproduce in a small test script, just when it runs the whole ruby koans. So the minimal way to reproduce I have is: download rubykoans: https://github.com/edgecase/ruby_koans/blob/master/download/rubykoans.zip?r… ``` unzip rubykoans.zip cd koans # fix deprecated method call for ruby 3.2 ruby -i -pe 'sub "File.exists", "File.exist"' neo.rb ``` Edit about_asserts.rb, adding these two statements to make a big array to the first koan: ``` def test_assert_truth array = [] 99130.times { array << "a string"} assert false # This should be true end ``` run `ruby path_to_enlightenment.rb` and get a backtrace like the attached backtrace.txt I've tried this on two servers, ubuntu aarch64 and debian x86_64. On both it crashes with ruby 3.2.2 and works fine with ruby 3.1. On both I installed ruby built from source with RVM. On the server with more ram I had to increase the number more (above it's 99130) to get it to crash. ---Files-------------------------------- backtrace.txt (21.7 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114381] [Ruby master Bug#19838] Ripper nested heredocs
by kddnewton (Kevin Newton) 12 Aug '23

12 Aug '23

Issue #19838 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19838: Ripper nested heredocs https://bugs.ruby-lang.org/issues/19838 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I'm seeing some odd behavior on nested heredocs in the ripper lexer. ``` ruby <<~H1 1 #{<<~H2} 2 H2 3 H1 ``` $ cat test.rb | ruby -rripper -e 'pp Ripper.lex(ARGF.read)' ``` ruby [[[1, 0], :on_heredoc_beg, "<<~H1", BEG], [[1, 5], :on_nl, "\n", BEG], [[2, 0], :on_ignored_sp, " ", BEG], [[2, 2], :on_tstring_content, "1\n", BEG], [[3, 0], :on_ignored_sp, " ", BEG], [[3, 2], :on_embexpr_beg, "\#{", BEG], [[3, 4], :on_heredoc_beg, "<<~H2", BEG], [[3, 9], :on_embexpr_end, "}", END], [[3, 10], :on_tstring_content, "\n", BEG], [[4, 0], :on_ignored_sp, " ", BEG], [[4, 4], :on_tstring_content, "2\n", BEG], [[5, 0], :on_heredoc_end, " H2\n", BEG], [[6, 0], :on_ignored_sp, " ", BEG], [[6, 2], :on_tstring_content, "3\n", BEG], [[7, 0], :on_heredoc_end, "H1\n", BEG]] ``` This seems totally correct. But if you change it to a non-indenting heredoc: ``` ruby <<-H1 1 #{<<~H2} 2 H2 3 H1 ``` $ cat test.rb | ruby -rripper -e 'pp Ripper.lex(ARGF.read)' ``` ruby [[[1, 0], :on_heredoc_beg, "<<-H1", BEG], [[1, 5], :on_nl, "\n", BEG], [[2, 0], :on_tstring_content, " 1\n" + " ", BEG], [[3, 2], :on_embexpr_beg, "\#{", BEG], [[3, 4], :on_heredoc_beg, "<<~H2", BEG], [[3, 9], :on_embexpr_end, "}", END], [[3, 10], :on_tstring_content, "\n" + " 3\n", BEG], [[4, 0], :on_ignored_sp, " ", BEG], [[4, 4], :on_tstring_content, "2\n", BEG], [[5, 0], :on_heredoc_end, " H2\n", BEG], [[7, 0], :on_heredoc_end, "H1\n", BEG]] ``` Now the newline on line 3 gets concatenated with the content from line 6, and that token is dropped from the list entirely. This seems unintentional, but I'm not sure. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114365] [Ruby master Bug#19834] Segmentation fault while running in docker
by ramachandran＠mallow-tech.com (Ramachandran A) 09 Aug '23

09 Aug '23

Issue #19834 has been reported by ramachandran(a)mallow-tech.com (Ramachandran A). ---------------------------------------- Bug #19834: Segmentation fault while running in docker https://bugs.ruby-lang.org/issues/19834 * Author: ramachandran(a)mallow-tech.com (Ramachandran A) * Status: Open * Priority: Normal * ruby -v: 2.6.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` 2023-08-09 12:44:32 /usr/local/lib/ruby/2.6.0/openssl/buffering.rb:383: [BUG] Illegal instruction at 0x0000ffff90d911a0 2023-08-09 12:44:32 ruby 2.6.3p62 (2019-04-16 revision 67580) [aarch64-linux] 2023-08-09 12:44:32 2023-08-09 12:44:32 -- Control frame information ----------------------------------------------- 2023-08-09 12:44:32 c:0046 p:---- s:0274 e:000273 CFUNC :syswrite_nonblock 2023-08-09 12:44:32 c:0045 p:0013 s:0268 e:000267 METHOD /usr/local/lib/ruby/2.6.0/openssl/buffering.rb:383 2023-08-09 12:44:32 c:0044 p:0021 s:0261 e:000260 BLOCK /usr/local/lib/ruby/2.6.0/net/protocol.rb:277 [FINISH] 2023-08-09 12:44:32 c:0043 p:---- s:0253 e:000252 IFUNC 2023-08-09 12:44:32 c:0042 p:---- s:0250 e:000249 CFUNC :each 2023-08-09 12:44:32 c:0041 p:---- s:0247 e:000246 CFUNC :each_with_index ``` I am using Ruby 2.6.3 in my project. It works fine until this week, I don't know why this is occurring. I have tried the solution mentioned in https://bugs.ruby-lang.org/issues/18555#note-6 the above issue, but it doesn't solve my problem. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:114221] [Ruby master Bug#19771] Backport 79a4484, abfac22
by krk (Kerem Kat) 08 Aug '23

08 Aug '23

Issue #19771 has been reported by krk (Kerem Kat). ---------------------------------------- Bug #19771: Backport 79a4484, abfac22 https://bugs.ruby-lang.org/issues/19771 * Author: krk (Kerem Kat) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- * https://github.com/ruby/ruby/commit/79a4484a072e9769b603e7b4fbdb15b1d7eccb15 * https://github.com/ruby/ruby/commit/abfac2222bd51a03ec11b64f4770179cb6d06515 Related backport PR: https://github.com/ruby/ruby/pull/8023 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114342] [Ruby master Feature#19830] Allow `Array#transpose` to take an optional size argument
by tomstuart (Tom Stuart) 04 Aug '23

04 Aug '23

Issue #19830 has been reported by tomstuart (Tom Stuart). ---------------------------------------- Feature #19830: Allow `Array#transpose` to take an optional size argument https://bugs.ruby-lang.org/issues/19830 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal ---------------------------------------- One benefit of supplying an initial value to `Enumerable#inject` is that it avoids an annoying edge case when the collection is empty: ``` >> [1, 2, 3].inject(:+) => 6 # good >> [].inject(:+) => nil # bad >> [].inject(0, :+) => 0 # good ``` A similar edge case exists for `Array#transpose`: ``` >> [[1, :a], [2, :b], [3, :c]].transpose => [[1, 2, 3], [:a, :b, :c]] # good >> [].transpose => [] # bad ``` Although no explicit `nil` is produced here, the subtle problem is that the caller may assume that the result array contains arrays, and that assumption leads to `nil`s in the empty case: ``` >> [[1, :a], [2, :b], [3, :c]].transpose.then { _2.join } => "abc" >> [].transpose.then { _2.join } undefined method `join' for nil:NilClass (NoMethodError) ``` If we allow `Array#transpose` to take an optional argument specifying the size of the result array, we can use this to always return an array of the correct size: ``` >> [[1, :a], [2, :b], [3, :c]].transpose(2) => [[1, 2, 3], [:a, :b, :c]] # good >> [].transpose(2) => [[], []] # good ``` By avoiding an unexpectedly empty result array, we also avoid unexpected downstream `nil`s: ``` >> [[1, :a], [2, :b], [3, :c]].transpose(2).then { _2.join } => "abc" >> [].transpose(2).then { _2.join } => "" ``` Here is a patch which adds an optional argument to `Array#transpose` to support the above usage: https://github.com/ruby/ruby/pull/8167 Something similar was requested eleven years ago in #6852. I believe this feature addresses the problem expressed in that issue without compromising backward compatibility with existing callers of #transpose. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113096] [Ruby master Feature#19572] Proposal: New TracePoint event for rescued exceptions
by st0012 (Stan Lo) 02 Aug '23

02 Aug '23

Issue #19572 has been reported by st0012 (Stan Lo). ---------------------------------------- Feature #19572: Proposal: New TracePoint event for rescued exceptions https://bugs.ruby-lang.org/issues/19572 * Author: st0012 (Stan Lo) * Status: Open * Priority: Normal ---------------------------------------- **Summary** Support a new `rescue` event type in TracePoint. When the event is triggered, `TracePoint#rescued_exception` can be used to access the exception. **Reason** Currently, TracePoint supports `raise` events, which can be helpful for debugging by showing which exception occurs at which location. By adding a `rescue` event type, we can improve the developer's debugging experience by making it easier to check where an exception is rescued. Currently, the most effective way to check where an exception is rescued involves setting a breakpoint at the exception's raised location and stepping through the code to see whether the debugger stops inside a rescue block. However, this can be a tedious process, especially in large applications with deep call stacks. By using a TracePoint event for rescue, developers can easily track exceptions as they are rescued by adding a few lines of code: ``` TracePoint.trace(:rescue) do |tp| puts "Exception rescued: #{tp.rescued_exception} at #{tp.path}:#{tp.lineno}" end ``` This new TracePoint event will also improve the `ruby/debug`'s [`ExceptionTracer`](https://github.com/ruby/debug/blob/master/lib/debug/tracer.rb#L150-L166) and provide users with a better debugging experience. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:114333] [Ruby master Bug#19795] attr_accessor leading to nil values for re-assignment
by francktrouillez (Franck Trouillez) 02 Aug '23

02 Aug '23

Issue #19795 has been reported by francktrouillez (Franck Trouillez). ---------------------------------------- Bug #19795: attr_accessor leading to nil values for re-assignment https://bugs.ruby-lang.org/issues/19795 * Author: francktrouillez (Franck Trouillez) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ### Steps to reproduce: - Create a class with an `attr_accessor` for an instance variable - Create an instance method that reassign this variable using the current value stored in the variable - Show that the variable is set to nil during the evaluation Code snippet: ``` ruby # attr_accessor_nil.rb class A attr_accessor :a def initialize @a = 1 end def my_method puts "a is '#{a.inspect}' of class '#{a.class}'" a += 1 if a.positive? # use an integer method end end instance = A.new instance.my_method # output: # # a is '1' of class 'Integer' # attr_accessor_nil.rb:12:in `my_method': undefined method `positive?' for nil:NilClass (NoMethodError) # # a += 1 if a.positive? # use an integer method # ^^^^^^^^^^ # from attr_accessor_nil.rb:17:in `<main>' ``` ### Expected behavior `a += 1` should lead to `a` being equal to `1` at the end of the assignment, because `a` was storing `0` previously, as shown by the `puts`. Am I being wrong expecting this result? ### Actual behavior `a += 1` raises an error about `a` being `nil` in the evaluation. ### Further investigation I checked if it was coming from the "instance variable", or about the "attr_accessor" by running the following snippet: Code snippet: ```ruby # attr_accessor_nil.rb class A attr_accessor :a def initialize @a = 0 end def my_method puts "a is '#{a.inspect}' of class '#{a.class}'" @a += 1 # use the instance variable directly, instead of the accessor end end instance = A.new instance.my_method # output: # # a is '1' of class 'Integer' ``` This snippet runs just fine, and no error is raised. ### System configuration Ruby version : 3.2.2 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:114295] [Ruby master Bug#19786] Data::define() does not work as documented
by thyresias (Thierry Lambert) 29 Jul '23

29 Jul '23

Issue #19786 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #19786: Data::define() does not work as documented https://bugs.ruby-lang.org/issues/19786 * Author: thyresias (Thierry Lambert) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Not sure if this is a bug or a feature. RDoc documentation for Data::define: > define(name, *symbols) → class > define(*symbols) → class > > Defines a new Data class. > If the first argument is a string, the class is stored in Data::<name> constant. ```ruby M1 = Data.define('Measure', :amount, :unit) p M1 #=> M1 p M1.members #=> [:Measure, :amount, :unit] S1 = Struct.new('Measure', :amount, :unit) p S1 #=> Struct::Measure p S1.members #=> [:amount, :unit] ``` Unlike `Struct.new`, `Data.define` does not accept a name as first argument: it converts it to a symbol, and therefore a member. There is no trace of `Data::Measure` in the example above, while we do have `Struct::Measure`. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:114298] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by k0kubun (Takashi Kokubun) 26 Jul '23

26 Jul '23

Issue #19057 has been updated by k0kubun (Takashi Kokubun). `cool.io` is another gem broken by this feature. FYI, I filed a pull request here https://github.com/tarcieri/cool.io/pull/79. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-103996 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.3 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0