Issue #19533 has been reported by knu (Akinori MUSHA).
----------------------------------------
Bug #19533: Behavior of ===/include? on a beginless/endless range (nil..nil) changed in ruby 3.2
https://bugs.ruby-lang.org/issues/19533
* Author: knu (Akinori MUSHA)
* Status: Open
* Priority: Normal
* Target version: 3.2
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-darwin22]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Starting from Ruby 2.7.0 a range `nil..nil` used to match any value until 3.2.0-preview3, but 3.2.0-rc1 started to reject it.
```
% docker run -it --rm rubylang/all-ruby ./all-ruby -e 'p( (nil..nil) === 1 )'
(snip)
ruby-2.6.10 false
ruby-2.7.0-preview1 true
...
ruby-3.2.0-preview3 true
ruby-3.2.0-rc1 -e:1:in `===': cannot determine inclusion in beginless/endless ranges (TypeError)
p( (nil..nil) === 1 )
^
from -e:1:in `<main>'
exit 1
...
ruby-3.2.1 -e:1:in `===': cannot determine inclusion in beginless/endless ranges (TypeError)
p( (nil..nil) === 1 )
^
from -e:1:in `<main>'
```
The previous behavior was so useful because when you have optional lower and upper bounds `lbound..rbound` would always work regardless of each end being nil or not.
There is no mention of this in doc/NEWS/NEWS-3.2.0.md, so I'm afraid it was caused unintentionally while fixing other problems.
```
% docker run -it --rm rubylang/all-ruby ./all-ruby -e 'p( (nil..nil).cover?(1) )'
(snip)
ruby-2.6.10 false
ruby-2.7.0-preview1 true
...
ruby-3.2.1 true
```
This was pointed out by the following blog article (written in Japanese) as a "pitfall" that you need to work around when upgrading Ruby from 3.0/3.1 to 3.2.
https://blog.studysapuri.jp/entry/2023/03/16/ujihisa-ruby32#endless-range%E…
--
https://bugs.ruby-lang.org/
Issue #19589 has been reported by alpaca-tc (Hiroyuki Ishii).
----------------------------------------
Bug #19589: Expecting stack overflow but crashing
https://bugs.ruby-lang.org/issues/19589
* Author: alpaca-tc (Hiroyuki Ishii)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-04-11T00:54:20Z master 65e276096f) [arm64-darwin22]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
The following code expects stack overflow but crashes.
The version it occurs in is newer than 3.2.0.
```
def expect_system_stack_error(h)
h.each_key {}
h.each_value { expect_system_stack_error(h) }
end
expect_system_stack_error(a: nil)
```
--
https://bugs.ruby-lang.org/
Issue #19595 has been reported by jhawthorn (John Hawthorn).
----------------------------------------
Bug #19595: YJIT: Crash from missing argc check in known cfuncs
https://bugs.ruby-lang.org/issues/19595
* Author: jhawthorn (John Hawthorn)
* Status: Open
* Priority: Normal
* Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED
----------------------------------------
https://github.com/ruby/ruby/pull/7697
Previously we were missing a compile-time check that the known cfuncs receive the correct number of arguments.
```
$ ruby --yjit-call-threshold=1 -e '"foo".to_s(*[])'
ruby: YJIT has panicked. More info to follow...
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
left: `1`,
right: `2`', ./yjit/src/codegen.rs:7225:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
-e:1: [BUG] YJIT panicked
ruby 3.3.0dev (2023-04-08T18:54:01Z master 671cfc2000) +YJIT [x86_64-linux]
```
This likely needs a backport to Ruby 3.2, Ruby 3.1 does not have this bug
--
https://bugs.ruby-lang.org/
Issue #19582 has been reported by renodr (Douglas R. Reno).
----------------------------------------
Bug #19582: Segmentation fault when running the tests for Ruby 3.2.2
https://bugs.ruby-lang.org/issues/19582
* Author: renodr (Douglas R. Reno)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
When adding a package update to BLFS, our policy is to run the tests for the packages. When running the tests for Ruby-3.2.2, we're getting a segmentation fault that appears to happen in TestNumeric#test_step. I've attached a copy of Ruby's crash output. Note that Ruby reports itself as "Ruby 3.2.1" here for some reason, even if /usr/bin/ruby is moved out of the way. I'm assuming that this is because of the 'miniruby' program that the build system compiles.
Note that if we bypass this segmentation fault by removing the test from test/ruby/test_numeric.rb, we later get an error that reads:
/sources/ruby-3.2.2/ruby-3.2.2/tool/lib/leakchecker.rb:238:in `block in check_env': uninitialized constant Bundler::EnvironmentPreserver (NameError)
next if k.start_with?(Bundler::EnvironmentPreserver::BUNDLER_PREFIX)
(Looking at Github, that would be added by commit 6d835901575d58e7db404665801a1c455ee982a8)
For package versions, we're running gcc-12.2.0, glibc-2.37, and Binutils-2.40. I noticed that it looked for rust when checking the configure output - we're running rustc-1.68.2. The base system is Linux From Scratch 11.3.
Some important information from the output:
[BUG] Segmentation fault at 0x0000000000000003
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0004 p:---- s:0012 e:000011 CFUNC :step
c:0003 p:---- s:0009 e:000008 CFUNC :each
c:0002 p:---- s:0006 e:000005 IFUNC
c:0001 p:---- s:0003 e:000002 DUMMY [FINISH]
-- Ruby level backtrace information ----------------------------------------
./test/runner.rb: TestNumeric#test_step:0:in `each'
./test/runner.rb: TestNumeric#test_step:0:in `step'
Thank you for your patience!
---Files--------------------------------
ruby-tests.log (454 KB)
--
https://bugs.ruby-lang.org/
Issue #19575 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #19575: Crash in Time on 32-bit systems
https://bugs.ruby-lang.org/issues/19575
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/7650
struct vtm is packed causing it to have a size that is not aligned on 32-bit systems. When allocating it on the stack, it will have unaligned addresses which means that the fields won't be marked by the GC when scanning the stack (since the GC only marks aligned addresses). This can cause crashes when the fields are heap allocated objects like Bignums.
The proposed fix moves the flags in struct time_object into struct vtm for space efficiency and removes the need for packing.
This is an example of a crash:
ruby(rb_print_backtrace+0xd) [0x56848945] ../src/vm_dump.c:785
ruby(rb_vm_bugreport) ../src/vm_dump.c:1101
ruby(rb_assert_failure+0x7a) [0x56671857] ../src/error.c:878
ruby(vm_search_cc+0x0) [0x56666e47] ../src/vm_method.c:1366
ruby(rb_vm_search_method_slowpath) ../src/vm_insnhelper.c:2090
ruby(callable_method_entry+0x5) [0x568232d3] ../src/vm_method.c:1406
ruby(rb_callable_method_entry) ../src/vm_method.c:1413
ruby(gccct_method_search_slowpath) ../src/vm_eval.c:427
ruby(gccct_method_search+0x20f) [0x568237ef] ../src/vm_eval.c:476
ruby(opt_equality_by_mid_slowpath+0x2c) [0x5682388c] ../src/vm_insnhelper.c:2338
ruby(rb_equal+0x37) [0x566fe577] ../src/object.c:133
ruby(rb_big_eq+0x34) [0x56876ee4] ../src/bignum.c:5554
ruby(rb_int_equal+0x14) [0x566f3ed4] ../src/numeric.c:4640
ruby(rb_int_equal) ../src/numeric.c:4634
ruby(vm_call0_cfunc_with_frame+0x6d) [0x568303c2] ../src/vm_eval.c:148
ruby(vm_call0_cfunc) ../src/vm_eval.c:162
ruby(vm_call0_body) ../src/vm_eval.c:208
ruby(rb_funcallv_scope+0xd1) [0x56833971] ../src/vm_eval.c:85
ruby(RB_TEST+0x0) [0x567e8488] ../src/time.c:78
ruby(eq) ../src/time.c:78
ruby(small_vtm_sub) ../src/time.c:1523
ruby(timelocalw+0x23b) [0x567f3e9b] ../src/time.c:1593
ruby(time_s_alloc+0x0) [0x567f536b] ../src/time.c:3698
ruby(time_new_timew) ../src/time.c:2694
ruby(time_s_mktime) ../src/time.c:3698
--
https://bugs.ruby-lang.org/
Issue #19550 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #19550: Memory leak in iclass for 32 bit systems
https://bugs.ruby-lang.org/issues/19550
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED
----------------------------------------
If !RCLASS_EXT_EMBEDDED (e.g. 32 bit systems) then the rb_classext_t is allocated throug malloc so it must be freed.
The issue can be seen in the following script:
```ruby
20.times do
100_000.times do
mod = Module.new
Class.new do
include mod
end
end
# Output the Resident Set Size (memory usage, in KB) of the current Ruby process
puts `ps -o rss= -p #{$$}`
end
```
Before this fix, the max RSS is 280MB, while after this change, it's 30MB.
--
https://bugs.ruby-lang.org/
Issue #19482 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #19482: Fix crash when allocating classes with newobj hook
https://bugs.ruby-lang.org/issues/19482
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/7464
We need to zero out the whole slot when running the newobj hook for a newly allocated class because the slot could be filled with garbage, which would cause a crash if a GC runs inside of the newobj hook.
For example, the following script crashes:
```ruby
require "objspace"
GC.stress = true
ObjectSpace.trace_object_allocations {
100.times do
Class.new
end
}
```
--
https://bugs.ruby-lang.org/