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

[ruby-core:113165] [Ruby master Bug#19587] Segmentation fault with ruby 3.2.0 - when running rspec suit.
by rubanthilak (Ruban Thilak) 17 Jul '23

17 Jul '23

Issue #19587 has been reported by rubanthilak (Ruban Thilak). ---------------------------------------- Bug #19587: Segmentation fault with ruby 3.2.0 - when running rspec suit. https://bugs.ruby-lang.org/issues/19587 * Author: rubanthilak (Ruban Thilak) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The segmentation fault occurs when this particular regex match happens while running the entire Rspec test suit. ```ruby it 'returns nil after timeout for untrusted regex' do extracted_value = described_class.extract('test1-test2-test3-test4-test_5', '^([0-9a-zA-Z\-/]*){1,256}$') expect(extracted_value).to be_nil end ``` But when I try to run only that particular spec file, segmentation fault does not occur. ``` ruby /runner/_work/Event_Mgmt_Service/Event_Mgmt_Service/lib/regex/parser.rb:17: [BUG] Segmentation fault at 0x0000706c4c1ada0c ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0048 p:---- s:0243 e:000242 CFUNC :match? c:0047 p:0016 s:0238 e:000237 METHOD /runner/_work/.../lib/regex/parser.rb:17 c:0046 p:0009 s:0230 e:000229 BLOCK /runner/_work/.../spec/lib/regex/parser_spec.rb:22 [FINISH] c:0045 p:---- s:0226 e:000225 CFUNC :instance_exec c:0044 p:0022 s:0221 e:000220 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:263 c:0043 p:0002 s:0216 e:000215 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:511 c:0042 p:0002 s:0213 e:000212 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:468 c:0041 p:0002 s:0210 e:000209 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:486 c:0040 p:0002 s:0207 e:000206 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:626 c:0039 p:0018 s:0204 e:000203 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:352 c:0038 p:0008 s:0198 e:000197 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-rails-4.1.2/lib/rspec/rails/adapters.rb:75 [FINISH] c:0037 p:---- s:0194 e:000193 CFUNC :instance_exec c:0036 p:0013 s:0189 e:000188 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:457 c:0035 p:0010 s:0183 e:000182 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:390 c:0034 p:0009 s:0177 e:000176 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:628 c:0033 p:0018 s:0174 e:000173 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:352 c:0032 p:0004 s:0168 e:000167 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/webmock-3.18.1/lib/webmock/rspec.rb:37 [FINISH] c:0031 p:---- s:0164 e:000163 CFUNC :instance_exec c:0030 p:0013 s:0159 e:000158 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:457 c:0029 p:0010 s:0153 e:000152 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:390 c:0028 p:0009 s:0147 e:000146 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:628 c:0027 p:0018 s:0144 e:000143 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:352 c:0026 p:0037 s:0138 E:0024f8 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:629 c:0025 p:0104 s:0131 E:002588 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/hooks.rb:486 c:0024 p:0018 s:0124 E:0009c8 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:468 c:0023 p:0019 s:0119 E:000a58 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:511 c:0022 p:0076 s:0114 E:000768 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example.rb:259 c:0021 p:0037 s:0107 e:000106 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example_group.rb:646 [FINISH] c:0020 p:---- s:0101 e:000100 CFUNC :map c:0019 p:0011 s:0097 e:000096 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example_group.rb:642 c:0018 p:0052 s:0092 e:000091 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example_group.rb:607 c:0017 p:0006 s:0083 e:000082 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example_group.rb:608 [FINISH] c:0016 p:---- s:0079 e:000078 CFUNC :map c:0015 p:0065 s:0075 e:000074 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/example_group.rb:608 c:0014 p:0007 s:0066 e:000065 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:121 [FINISH] c:0013 p:---- s:0062 e:000061 CFUNC :map c:0012 p:0030 s:0058 e:000057 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:121 c:0011 p:0026 s:0055 e:000054 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/configuration.rb:2070 c:0010 p:0007 s:0051 e:000050 BLOCK /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:116 c:0009 p:0009 s:0047 e:000046 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/reporter.rb:74 c:0008 p:0019 s:0042 e:000041 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:115 c:0007 p:0035 s:0035 e:000034 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:89 c:0006 p:0058 s:0029 e:000028 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:71 c:0005 p:0013 s:0021 e:000020 METHOD /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/lib/rspec/core/runner.rb:45 c:0004 p:0010 s:0016 e:000015 TOP /opt/hostedtoolcache/Ruby/3.2.0/x64/lib/ruby/gems/3.2.0/gems/rspec-core-3.12.1/exe/rspec:4 [FINISH] c:0003 p:---- s:0013 e:000012 CFUNC :load c:0002 p:0078 s:0008 E:0025f0 EVAL /opt/hostedtoolcache/Ruby/3.2.0/x64/bin/rspec:25 [FINISH] c:0001 p:0000 s:0003 E:0018a0 DUMMY [FINISH] ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:113205] [Ruby master Bug#19595] YJIT: Crash from missing argc check in known cfuncs
by jhawthorn (John Hawthorn) 17 Jul '23

17 Jul '23

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/

2 1

[ruby-core:113141] [Ruby master Bug#19582] Segmentation fault when running the tests for Ruby 3.2.2
by renodr (Douglas R. Reno) 17 Jul '23

17 Jul '23

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/

4 4

[ruby-core:113106] [Ruby master Bug#19575] Crash in Time on 32-bit systems
by peterzhu2118 (Peter Zhu) 17 Jul '23

17 Jul '23

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/

2 1

[ruby-core:113026] [Ruby master Bug#19550] Memory leak in iclass for 32 bit systems
by peterzhu2118 (Peter Zhu) 17 Jul '23

17 Jul '23

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/

2 2

[ruby-core:114202] [Ruby master Bug#19084] Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer
by nagachika (Tomoyuki Chikanaga) 16 Jul '23

16 Jul '23

Issue #19084 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: REQUIRED, 3.2: REQUIRED to 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: REQUIRED, 3.2: DONE ruby_3_2 c911cbd6c3dcc80def61ab48be1815cd910fc91b merged revision(s) bd786e78969f9d4a8699376ceafe10934b6ad533. ---------------------------------------- Bug #19084: Using `IO::Buffer` to change an extended String affects other Strings sharing the same buffer https://bugs.ruby-lang.org/issues/19084#change-103889 * Author: jemmai (Jemma Issroff) * Status: Closed * Priority: Normal * ruby -v: master * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- When two extended Strings share a buffer, and one String's buffer changes, it currently affects the other String's buffer. Here is a snippet to demonstrate this: ``` string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" other_string = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" IO::Buffer.for(string) do |buffer| buffer.set_value(:U8, 0, "*".ord) end other_string[0] == "a" # => false ``` [Here is a PR which adds the above example as a test](https://github.com/ruby/ruby/pull/6630), and is currently failing CI. (cc @ioquatix) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113005] [Ruby master Bug#19546] IO::Buffer is incorrectly invoking fiber scheduler interface.
by ioquatix (Samuel Williams) 16 Jul '23

16 Jul '23

Issue #19546 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19546: IO::Buffer is incorrectly invoking fiber scheduler interface. https://bugs.ruby-lang.org/issues/19546 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The `IO::Buffer` implementation incorrectly calls rb_fiber_scheduler_io_write with the size_ts converted to VALUEs: https://github.com/ruby/ruby/blob/400ccb16eefe4e21c4e3eacab4fd0f208fc5e151/… But that function expects size_ts: https://github.com/ruby/ruby/blob/400ccb16eefe4e21c4e3eacab4fd0f208fc5e151/… (And probably the same for the other scheduler methods.) Fixed by <https://github.com/ruby/ruby/pull/7593>. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112721] [Ruby master Bug#19482] Fix crash when allocating classes with newobj hook
by peterzhu2118 (Peter Zhu) 16 Jul '23

16 Jul '23

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/

2 1

[ruby-core:112723] [Ruby master Bug#19483] rubyzip not behaving well with YJIT
by k0kubun (Takashi Kokubun) 16 Jul '23

16 Jul '23

Issue #19483 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19483: rubyzip not behaving well with YJIT https://bugs.ruby-lang.org/issues/19483 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: yjit * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- Copied from https://github.com/Shopify/yjit/issues/310 for backports. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112578] [Ruby master Bug#19463] YJIT `[BUG] Stack consistency error` under certain invalidation scenarios
by alanwu (Alan Wu) 16 Jul '23

16 Jul '23

Issue #19463 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #19463: YJIT `[BUG] Stack consistency error` under certain invalidation scenarios https://bugs.ruby-lang.org/issues/19463 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [arm64-darwin22] * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- > test.rb:19: [BUG] Stack consistency error (sp: 15, bp: 16) With the following: ```ruby klass = Class.new do def self.lookup(hash, key) = hash[key] def self.foo(a, b) = [] def self.test(hash, key) [lookup(hash, key), key, "".freeze] # 05 opt_send_without_block :lookup # 07 getlocal_WC_0 :hash # 09 opt_str_freeze "" # 12 newarray 3 # 14 leave # # YJIT will put instructions (07..14) into a block. # When String#freeze is redefined from within lookup(), # the return address to the block is still on-stack. We rely # on invalidation patching the code at the return address # to service this situation correctly. end end # get YJIT to compile test() hash = { 1 => [] } 31.times { klass.test(hash, 1) } # inject invalidation into lookup() evil_hash = Hash.new do |_, key| class String undef :freeze def freeze = :ugokanai end key end p klass.test(evil_hash, 1) ``` The fix is fairly simple and I'll apply it shortly. -- https://bugs.ruby-lang.org/

2 1