November 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:115117] [Ruby master Bug#19967] Already installed libruby.dylib is used for test on macOS
by nobu (Nobuyoshi Nakada) 24 Jan '25

24 Jan '25

Issue #19967 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19967: Already installed libruby.dylib is used for test on macOS https://bugs.ruby-lang.org/issues/19967 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- On macOS, in the case of `--enable-shared` and `--disable-load-relative`, already install libruby.dylib is used during tests if exists. This is because since [Bug #14992], `DYLD_FALLBACK_LIBRARY_PATH` is used instead of `DYLD_LIBRARY_PATH`. The latter environment variable is used preferentially, whereas the former is used as a fallback, as the name implies. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116640] [Ruby master Feature#20249] Print only backtraces in rb_bug(), by default
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #20249 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #20249: Print only backtraces in rb_bug(), by default https://bugs.ruby-lang.org/issues/20249 * Author: osyoyu (Daisuke Aritomo) * Status: Open * Priority: Normal ---------------------------------------- ## Background When a segfault or some unexpected situation occurs, `rb_bug()` is called and prints some few hundred to thousands of lines. The most helpful parts are (arguably) "Ruby level backtrace information" and "C-level backtrace information", but those parts are buried in the very lengthy report. In particular, the "Other runtime information" which contains the list of loaded features (scripts?) and the process memory map could be extremely long despite it does not come very useful, at least when developing C extensions. Even a minimal report from a simple script would consist of 250 lines and require 7 PgUps on my MacBook Air (13 inch) to reach the backtrace part, which contains all the information I need. ## Proposal My proposal is to default to a "minimal report" mode with a limited set of sections, perhaps only "Ruby level backtrace information" and "C level backtrace information" only When a full report is desired (i.e. for bug reports), the user could re-run the script with an special environment variable, such as `RUBY_FULL_CRASH_REPORT=1`. Rust implmements a similar pattern. It doesn't print the full backtrace on panics by default; instead, it guides the user to re-run the program with `RUST_BACKTRACE=1`. It might be hard to reproduce some crashes and segfaults, especially in long-running daemons. It might be nice to default to the "full" mode when stdout is not a tty, since daemons tend to run in non-tty environments. ## Appendix A typical crash report would look like this: ``` ../../example.rb: [BUG] ruby 3.4.0dev (2024-01-20T15:27:19Z master 366b14c0cd) [arm64-darwin23] -- Crash Report log information -------------------------------------------- (5 lines) -- Control frame information ----------------------------------------------- (~50 lines) -- Ruby level backtrace information ---------------------------------------- (depends on program; typically ~50 lines in Rails) -- C level backtrace information ------------------------------------------- (50+-ish lines, depends on program) -- Machine register context ------------------------------------------------ (~10 lines) -- Threading information --------------------------------------------------- (2 lines) -- Other runtime information ----------------------------------------------- * Loaded script (1 line) * Loaded features (depends on program; 800+ lines in Rails) * Process memory map (depends on environment; around 200 lines?) -- https://bugs.ruby-lang.org/

5 10

[ruby-core:111121] [Ruby master Bug#19165] Method (with no param) delegation with *, **, and ... is slow
by matsuda (Akira Matsuda) 16 Jan '25

16 Jan '25

Issue #19165 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19165: Method (with no param) delegation with *, **, and ... is slow https://bugs.ruby-lang.org/issues/19165 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-01T08:05:41Z master 4e68b59431) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I found that method delegation via Forwardable is much slower than normal method call when delegating a method that does not take parameters. Here's a benchmark that explains what I mean. ``` require 'forwardable' require 'pp' require 'benchmark/ips' class Obj extend Forwardable attr_accessor :other def initialize @other = Other.new end def foo_without_splat @other.foo end def foo_with_splat(*) @other.foo(*) end def foo_with_splat_with_name(*args) @other.foo(*args) end def foo_with_splat_and_double_splat(*, **) @other.foo(*, **) end def foo_with_triple_dots(...) @other.foo(...) end delegate :foo => :@other end class Other def foo() end end o = Obj.new Benchmark.ips do |x| x.report 'simple call' do o.other.foo end x.report 'delegate without splat' do o.foo_without_splat end x.report 'delegate with splat' do o.foo_with_splat end x.report 'delegate with splat with name' do o.foo_with_splat_with_name end x.report 'delegate with splat and double splat' do o.foo_with_splat_and_double_splat end x.report 'delegate with triple dots' do o.foo_with_triple_dots end x.report 'delegate via forwardable' do o.foo end end (result) simple call 38.918M (± 0.9%) i/s - 194.884M delegate without splat 31.933M (± 1.6%) i/s - 159.611M delegate with splat 10.269M (± 1.6%) i/s - 51.631M delegate with splat with name 9.888M (± 1.0%) i/s - 49.588M delegate with splat and double splat 4.117M (± 0.9%) i/s - 20.696M delegate with triple dots 4.169M (± 0.9%) i/s - 20.857M delegate via forwardable 9.204M (± 2.1%) i/s - 46.295M ``` It shows that Method delegation with a splat is 3-4 times slower (regardless of whether the parameter is named or not), and delegation with a triple-dot literal is 9-10 times slower than a method delegation without an argument. This may be because calling a method taking a splat always assigns an Array object even when no actual argument was given, and calling a method taking triple-dots assigns five Array objects and two Hash objects (this is equivalent to `*, **`). Are there any chance reducing these object assignments and making them faster? My concern is that the Rails framework heavily uses this kind of method delegations, and presumably it causes unignorable performance overhead. -- https://bugs.ruby-lang.org/

6 8

[ruby-core:120058] [Ruby master Bug#20924] IO#readline ignores the limit argument when the encoding is UTF-32LE and the limit would split a character
by javanthropus (Jeremy Bopp) 15 Jan '25

15 Jan '25

Issue #20924 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20924: IO#readline ignores the limit argument when the encoding is UTF-32LE and the limit would split a character https://bugs.ruby-lang.org/issues/20924 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.4.0dev (2024-11-28T12:38:16Z master 3af1a04741) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(binmode: true, encoding: 'utf-32le') do |f| f.write('0123456789') f.rewind # A limit that would truncate a character becomes completely ignored f.readline(3).bytesize # => 40; should be 4 end Tempfile.open(binmode: true, encoding: 'utf-32le') do |f| f.write('0123456789') f.rewind # A limit on character boundaries is respected f.readline(4).bytesize # => 4 end Tempfile.open(encoding: 'utf-8:utf-32le') do |f| f.write('0123456789') f.rewind # A limit that would truncate a character becomes completely ignored f.readline(3).bytesize # => 40; should be 4 end Tempfile.open(encoding: 'utf-8:utf-32le') do |f| f.write('0123456789') f.rewind # A limit on character boundaries is respected f.readline(4).bytesize # => 4 end ``` This doesn't happen with UTF-32BE. This also doesn't happen in Ruby 3.3, but it does happen in 3.4-dev and Ruby 3.0 - 3.2. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120048] [Ruby master Bug#20921] Use-after-free in constant cache
by peterzhu2118 (Peter Zhu) 15 Jan '25

15 Jan '25

Issue #20921 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20921: Use-after-free in constant cache https://bugs.ruby-lang.org/issues/20921 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: DONTNEED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/12203 When we create a cache entry for a constant, the following sequence of events could happen: - vm_track_constant_cache is called to insert a constant cache. - In vm_track_constant_cache, we first look up the ST table for the ID of the constant. Assume the ST table exists because another iseq also holds a cache entry for this ID. - We then insert into this ST table with the iseq_inline_constant_cache. - However, while inserting into this ST table, it allocates memory, which could trigger a GC. Assume that it does trigger a GC. - The GC frees the one and only other iseq that holds a cache entry for this ID. - In remove_from_constant_cache, it will appear that the ST table is now empty because there are no more iseq with cache entries for this ID, so we free the ST table. - We complete GC and continue our st_insert. However, this ST table has been freed so we now have a use-after-free. This issue is very hard to reproduce, because it requires that the GC runs at a very specific time. However, we can make it show up by applying this patch which runs GC right before the st_insert to mimic the st_insert triggering a GC: ```diff diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 3cb23f06f0..a93998136a 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -6338,6 +6338,10 @@ vm_track_constant_cache(ID id, void *ic) rb_id_table_insert(const_cache, id, (VALUE)ics); } + if (id == rb_intern("MyConstant")) rb_gc(); + st_insert(ics, (st_data_t) ic, (st_data_t) Qtrue); } ``` And if we run this script: ```ruby Object.const_set("MyConstant", "Hello!") my_proc = eval("-> { MyConstant }") my_proc.call my_proc = eval("-> { MyConstant }") my_proc.call ``` We can see that ASAN outputs a use-after-free error: ``` ==36540==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000049528 at pc 0x000102f3ceac bp 0x00016d607a70 sp 0x00016d607a68 READ of size 8 at 0x606000049528 thread T0 #0 0x102f3cea8 in do_hash st.c:321 #1 0x102f3ddd0 in rb_st_insert st.c:1132 #2 0x103140700 in vm_track_constant_cache vm_insnhelper.c:6345 #3 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #5 0x1030bc1e0 in vm_exec_core insns.def:263 #6 0x1030b55fc in rb_vm_exec vm.c:2585 #7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #8 0x102a82588 in rb_ec_exec_node eval.c:281 #9 0x102a81fe0 in ruby_run_node eval.c:319 #10 0x1027f3db4 in rb_main main.c:43 #11 0x1027f3bd4 in main main.c:68 #12 0x183900270 (<unknown module>) 0x606000049528 is located 8 bytes inside of 56-byte region [0x606000049520,0x606000049558) freed by thread T0 here: #0 0x104174d40 in free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54d40) #1 0x102ada89c in rb_gc_impl_free default.c:8183 #2 0x102ada7dc in ruby_sized_xfree gc.c:4507 #3 0x102ac4d34 in ruby_xfree gc.c:4518 #4 0x102f3cb34 in rb_st_free_table st.c:663 #5 0x102bd52d8 in remove_from_constant_cache iseq.c:119 #6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153 #7 0x102bbd2a0 in rb_iseq_free iseq.c:166 #8 0x102b32ed0 in rb_imemo_free imemo.c:564 #9 0x102ac4b44 in rb_gc_obj_free gc.c:1407 #10 0x102af4290 in gc_sweep_plane default.c:3546 #11 0x102af3bdc in gc_sweep_page default.c:3634 #12 0x102aeb140 in gc_sweep_step default.c:3906 #13 0x102aeadf0 in gc_sweep_rest default.c:3978 #14 0x102ae4714 in gc_sweep default.c:4155 #15 0x102af8474 in gc_start default.c:6484 #16 0x102afbe30 in garbage_collect default.c:6363 #17 0x102ad37f0 in rb_gc_impl_start default.c:6816 #18 0x102ad3634 in rb_gc gc.c:3624 #19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342 #20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #22 0x1030bc1e0 in vm_exec_core insns.def:263 #23 0x1030b55fc in rb_vm_exec vm.c:2585 #24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #25 0x102a82588 in rb_ec_exec_node eval.c:281 #26 0x102a81fe0 in ruby_run_node eval.c:319 #27 0x1027f3db4 in rb_main main.c:43 #28 0x1027f3bd4 in main main.c:68 #29 0x183900270 (<unknown module>) previously allocated by thread T0 here: #0 0x104174c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04) #1 0x102ada0ec in rb_gc_impl_malloc default.c:8198 #2 0x102acee44 in ruby_xmalloc gc.c:4438 #3 0x102f3c85c in rb_st_init_table_with_size st.c:571 #4 0x102f3c900 in rb_st_init_table st.c:600 #5 0x102f3c920 in rb_st_init_numtable st.c:608 #6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337 #7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #9 0x1030bc1e0 in vm_exec_core insns.def:263 #10 0x1030b55fc in rb_vm_exec vm.c:2585 #11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #12 0x102a82588 in rb_ec_exec_node eval.c:281 #13 0x102a81fe0 in ruby_run_node eval.c:319 #14 0x1027f3db4 in rb_main main.c:43 #15 0x1027f3bd4 in main main.c:68 #16 0x183900270 (<unknown module>) ``` This commit fixes this bug by adding a inserting_constant_cache_id field to the VM, which stores the ID that is currently being inserted and, in remove_from_constant_cache, we don't free the ST table for ID equal to this one. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120031] [Ruby master Bug#20915] Segfault with `TracePoint#parameters` and aliased C method
by viralpraxis (Iaroslav Kurbatov) 15 Jan '25

15 Jan '25

Issue #20915 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #20915: Segfault with `TracePoint#parameters` and aliased C method https://bugs.ruby-lang.org/issues/20915 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: 3.3.6 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I'm getting a segfault in the following example ```ruby C = Class.new do alias_method :new_to_s, :to_s end TracePoint.new(:c_call, &:parameters).enable { C.new.new_to_s } ``` Ruby: `MRI 3.3.6`, also `ruby 3.4.0dev (2024-11-27T19:36:50Z master 7dd2afbe3a) +PRISM [x86_64-linux]` The root cause of the issue lies in the `rb_tracearg_parameters` function within the `RUBY_EVENT_C_RETURN` branch. It seems like if invoked method is aliased to C function `rb_method_entry_without_refinements(..., trace_arg->called_id, ...)`. Specifically, when the invoked method is an alias for a C function, `rb_method_entry_without_refinements(..., trace_arg->called_id, ...)` may return NULL. In that case we can fallback to `trace_arg->id`. Output: ``` [BUG] Segmentation fault at 0x0000000000000010 ruby 3.4.0dev (2024-11-27T19:36:50Z master 7dd2afbe3a) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0022 e:000021 METHOD <internal:trace_point>:333 [FINISH] c:0004 p:0006 s:0018 e:000016 BLOCK test.rb:5 [FINISH] c:0003 p:0003 s:0014 e:000013 METHOD <internal:trace_point>:265 c:0002 p:0021 s:0006 e:000005 EVAL test.rb:5 [FINISH] c:0001 p:0000 s:0003 E:001470 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:5:in '<main>' <internal:trace_point>:265:in 'enable' test.rb:5:in 'block in <main>' <internal:trace_point>:333:in 'parameters' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x0000609a79ce6f16 RBP: 0x00007ffd98dc9030 RSP: 0x00007ffd98dc9020 RAX: 0x0000000000000000 RBX: 0x0000609a7b40bdf0 RCX: 0x000000000000b6d1 RDX: 0x0000000000000000 RDI: 0x0000000000000000 RSI: 0x0000000000000b6d R8: 0x0000000000000000 R9: 0x000076e90ee24aa0 R10: 0x0000000000000001 R11: 0x0000000000000010 R12: 0x0000000000000002 R13: 0x0000000000000000 R14: 0x0000609a7b40be08 R15: 0x000076e90effeef8 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- ./ruby(0x609a79e219f7) [0x609a79e219f7] ./ruby(0x609a79e2214b) [0x609a79e2214b] ./ruby(0x609a7a02e998) [0x609a7a02e998] ./ruby(0x609a79d61811) [0x609a79d61811] /lib/x86_64-linux-gnu/libc.so.6(0x76e90f845320) [0x76e90f845320] ./ruby(0x609a79ce6f16) [0x609a79ce6f16] ./ruby(rb_tracearg_parameters+0x1a1) [0x609a79e25db2] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:943 ./ruby(tracepoint_attr_parameters+0x21) [0x609a79e26252] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:1121 ./ruby(0x609a79df8f0b) [0x609a79df8f0b] ./ruby(0x609a79df9904) [0x609a79df9904] ./ruby(0x609a79df9983) [0x609a79df9983] ./ruby(0x609a79e0147e) [0x609a79e0147e] ./ruby(0x609a79e15d9c) [0x609a79e15d9c] ./ruby(0x609a79e09991) [0x609a79e09991] ./ruby(0x609a79e091bd) [0x609a79e091bd] ./ruby(0x609a79e0ad1f) [0x609a79e0ad1f] ./ruby(0x609a79e0ba2b) [0x609a79e0ba2b] ./ruby(rb_funcall_with_block_kw) [0x609a79e0c7ef] ./ruby(0x609a79d8d877) [0x609a79d8d877] ./ruby(0x609a79df3832) [0x609a79df3832] ./ruby(0x609a79e13238) [0x609a79e13238] ./ruby(0x609a79e13888) [0x609a79e13888] ./ruby(rb_proc_call_with_block_kw) [0x609a79ce3b6a] ./ruby(rb_proc_call_with_block) [0x609a79ce3bcf] ./ruby(tp_call_trace+0x8d) [0x609a79e2641c] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:1188 ./ruby(exec_hooks_body+0x114) [0x609a79e245d7] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:354 ./ruby(exec_hooks_protected+0x166) [0x609a79e24838] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:401 ./ruby(rb_exec_event_hooks+0x12d) [0x609a79e249e2] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:446 ./ruby(0x609a79ddbefe) [0x609a79ddbefe] ./ruby(0x609a79deef34) [0x609a79deef34] ./ruby(0x609a79def260) [0x609a79def260] ./ruby(0x609a79def38d) [0x609a79def38d] ./ruby(0x609a79def7d4) [0x609a79def7d4] ./ruby(0x609a79df243b) [0x609a79df243b] ./ruby(0x609a79df0646) [0x609a79df0646] ./ruby(0x609a79df2c0d) [0x609a79df2c0d] ./ruby(0x609a79df2ee7) [0x609a79df2ee7] ./ruby(0x609a79df30e9) [0x609a79df30e9] ./ruby(0x609a79df580a) [0x609a79df580a] ./ruby(0x609a79dfd8dd) [0x609a79dfd8dd] ./ruby(0x609a79e15d9c) [0x609a79e15d9c] ./ruby(0x609a79e12a8c) [0x609a79e12a8c] ./ruby(0x609a79e12c48) [0x609a79e12c48] ./ruby(0x609a79e12c86) [0x609a79e12c86] ./ruby(0x609a79e0cc8c) [0x609a79e0cc8c] ./ruby(rb_yield) [0x609a79e0cce0] ./ruby(rb_ensure) [0x609a79c20ea4] ./ruby(tracepoint_enable_m+0x1a5) [0x609a79e26c05] /home/viralpraxis/Documents/open_source/ruby/vm_trace.c:1414 ./ruby(0x609a79df8fd7) [0x609a79df8fd7] ./ruby(0x609a79df9904) [0x609a79df9904] ./ruby(0x609a79df99d1) [0x609a79df99d1] ./ruby(0x609a79e01583) [0x609a79e01583] ./ruby(0x609a79e15d9c) [0x609a79e15d9c] ./ruby(rb_iseq_eval_main) [0x609a79e16bcb] ./ruby(0x609a79c1f112) [0x609a79c1f112] ./ruby(ruby_run_node) [0x609a79c1f283] ./ruby(0x609a79c1aae4) [0x609a79c1aae4] ./ruby(0x609a79c1ab45) [0x609a79c1ab45] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x76e90f82a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x76e90f82a28b] ../csu/libc-start.c:360 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x609a79c1a9c5] -- Other runtime information ----------------------------------------------- * Loaded script: test.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120006] [Ruby master Bug#20909] Backport String indexing bug fixes
by nobu (Nobuyoshi Nakada) 15 Jan '25

15 Jan '25

Issue #20909 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20909: Backport String indexing bug fixes https://bugs.ruby-lang.org/issues/20909 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- commit:02b70256b5171d4b85ea7eeab836d3d7cfb3dbfc commit:6b4f8945d600168bf530d21395da8293fbd5e8ba -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119751] [Ruby master Bug#20871] Including methods in Enumerable doesn't make them available in Array
by sanderd17 (Sander Deryckere) 15 Jan '25

15 Jan '25

Issue #20871 has been reported by sanderd17 (Sander Deryckere). ---------------------------------------- Bug #20871: Including methods in Enumerable doesn't make them available in Array https://bugs.ruby-lang.org/issues/20871 * Author: sanderd17 (Sander Deryckere) * Status: Open * ruby -v: 3.3.6 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Today, our CI pipeline started failing after the automatic update from v3.3.5 to v3.3.6. After researching, it turned out that our core extensions to the `Array` class weren't loaded anymore. The core-extensions code looks like this: ```ruby module CoreExt module Enumerable def average sum(&:to_f) / count if any? end # def ... end end Enumerable.include CoreExt::Enumerable ``` After some debugging, it turned out that the `average` method was included in the `instance_methods` of `Enumerable`, but not in the `instance_methods` of `Array`. Explicitly adding `Array.include CoreExt::Enumerable` fixes CI for our case. The very strange thing is that it only happens on a release branch we are still maintaining. It doesn't happen on our main development branch (which also updated to v3.3.6 today). I have been unable to find the difference between both branches so far (they diverged a couple of months ago, but the base system is still regularly updated on both, and pretty similar). After some digging around, I assume this commit is related to our issue: https://github.com/ruby/ruby/commit/edeb0319f7a95dfe3f9b895bcf32371dd8514726 -- https://bugs.ruby-lang.org/

6 12

[ruby-core:119998] [Ruby master Bug#20907] Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted.
by ioquatix (Samuel Williams) 15 Jan '25

15 Jan '25

Issue #20907 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20907: Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted. https://bugs.ruby-lang.org/issues/20907 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- The following test fails with a `ThreadError` instead of a `RuntimeError`: ```ruby def test_condition_variable condition_variable = ::Thread::ConditionVariable.new mutex = ::Thread::Mutex.new error = nil thread = Thread.new do Thread.current.report_on_exception = false scheduler = Scheduler.new Fiber.set_scheduler scheduler fiber = Fiber.schedule do begin mutex.synchronize do condition_variable.wait(mutex) end rescue => error end end fiber.raise(RuntimeError) end thread.join assert_kind_of RuntimeError, error end ``` Fix: https://github.com/ruby/ruby/pull/12158 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119903] [Ruby master Bug#20892] `ObjectSpace.dump` can produce broken JSON for classes with temporary names
by byroot (Jean Boussier) 15 Jan '25

15 Jan '25

Issue #20892 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20892: `ObjectSpace.dump` can produce broken JSON for classes with temporary names https://bugs.ruby-lang.org/issues/20892 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- ```ruby puts ObjectSpace.dump(Class.new.tap { |c| c.set_temporary_name('" little boby table') }) ``` Produces the following JSON: ```json { "address":"0x120bea980", "type":"CLASS", "shape_id":2, "slot_size":160, "class":"0x120bea840", "variation_count":0, "superclass":"0x1041ffd38", "name":"" little boby table", "references":["0x1041ffd38", "0x123e71a98"], "memsize":192, "flags":{"wb_protected":true} } ``` Notice how the `name` property is broken. This only impacts 3.3.x, as that's when `set_temporary_name` was introduced, before that, it was impossible to assign a name that would cause such bug. -- https://bugs.ruby-lang.org/

2 1