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

[ruby-core:115483] [Ruby master Bug#20021] TestGCCompact#test_moving_hashes_down_size_pools is flaky
by kjtsanaktsidis (KJ Tsanaktsidis) 28 Nov '23

28 Nov '23

Issue #20021 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20021: TestGCCompact#test_moving_hashes_down_size_pools is flaky https://bugs.ruby-lang.org/issues/20021 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The test `TestGCCompact#test_moving_hashes_down_size_pools is flaky` is, I believe, flaky, and sometimes fails with this message: ``` 1) Failure: TestGCCompact#test_moving_hashes_down_size_pools [/home/chkbuild/chkbuild/tmp/build/20231112T183003Z/ruby/test/ruby/test_gc_compact.rb:442]: Expected 499 to be >= 500. ``` I started looking at this because when https://github.com/ruby/ruby/pull/8858 was merged, rubyci began failing on Ubuntu 22.04 with this message (https://rubyci.s3.amazonaws.com/ubuntu2204/ruby-master/log/20231112T183003Z…) I was able to reproduce this failure after _very_ carefully reproducing the ruibyci testing environment (same EC2 instance type, and I actually had to install _exactly_ the same kernel version as well!). After debugging the test, what I discovered is that the _last_ hash that was modified in the test is actually on the machine stack when `GC.verify_compaction_references` is called, which means it gets pinned and cannot be moved; thus, the test fails because only 499 out of 500 objects got moved! The hash's VALUE is "on the stack" in the sense that it's in a memory location below `%rsp`, but it is _NOT_ actually live in any C local variable. The stack address I found the VALUE in is part of the frame of `gc_start`, but `gc_start` obviously doesn't hold a reference to the hash from the test. Rather, it's left-behind in uninitialized memory. I think this is made more likely because of how GCC wound up compiling the `gc_start` function. It seems to have allocated quite a lot of stack space - 440 bytes of it - and very little of it seems to be used for local variables. Thus, a lot of this memory just contains assorted tidbits from previous VM execution state. This patch works around the issue, at least on my testbench, by running the code which touches the test hashes in a separate fiber. Each fiber gets its own machine stack, so references to the to-be-moved hashes shouldn't leak into the main stack, and this fiber's stack should be out of scope when the compaction is run, so it should get freed. https://github.com/ruby/ruby/pull/9040 The other approach I considered is counting the number of pinned objects, and asserting that (moved + pinned) >= 500 instead of just moved >= 500. However, it's very likely that there will be a pinned hash (or string, etc, for the other, similar test cases), so this would make the test pass even when it should not, I think. Also, since this these tests were skipped on Solaris because of this bug, I have unskipped them (although it seems we no longer have solaris on ruby ci, so I guess it doesn't matter). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115494] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by mame (Yusuke Endoh) 28 Nov '23

28 Nov '23

Issue #18886 has been updated by mame (Yusuke Endoh). @jeremyevans0 Could you measure the overhead? ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105423 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115489] [Ruby master Bug#20023] rb_require("noexist") causes segfault
by mtasaka (Mamoru Tasaka) 27 Nov '23

27 Nov '23

Issue #20023 has been reported by mtasaka (Mamoru Tasaka). ---------------------------------------- Bug #20023: rb_require("noexist") causes segfault https://bugs.ruby-lang.org/issues/20023 * Author: mtasaka (Mamoru Tasaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-27 master a07d84b63c) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Extracted from swig 4.1.1 testsuite. With commit:a07d84b63c (and probably with earlier commit), `rb_require("noexist") ;` seems segfault. foo.rb: ``` #!/usr/bin/env ruby begin require "bar" rescue LoadError => e p e.to_s end ``` bar.c: ``` #include <ruby.h> void Init_bar(void) { VALUE m_bar = rb_define_module("Bar"); rb_require("noexist"); } ``` Execute: ``` gcc -shared -I/usr/include -Wall -O2 -g -fpic -fPIC -o bar.so bar.c ruby -I. foo.rb ``` With `ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]`: OK ``` + ruby -I. foo.rb "cannot load such file -- noexist" ``` With `ruby 3.3.0dev (2023-11-27 master a07d84b63c) [x86_64-linux]`: ``` + ruby -I. foo.rb <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:129: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.3.0dev (2023-11-27 master a07d84b63c) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0020 s:0019 e:000016 RESCUE <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:129 c:0003 p:0024 s:0013 e:000012 METHOD <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:126 c:0002 p:0005 s:0007 E:000818 EVAL foo.rb:4 [FINISH] c:0001 p:0000 s:0003 E:001d70 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- foo.rb:4:in `<main>' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:126:in `require' <internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:129:in `rescue in require' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00007feedd015807 RBP: 0x00007ffd9f27ad00 RSP: 0x00007ffd9f27ac98 RAX: 0x000000000000008c RBX: 0x0000008c00100003 RCX: 0x00007feedd34dc78 RDX: 0x00007ffd9f27acb8 RDI: 0x0041710f058b48c3 RSI: 0x000000000000008c R8: 0x00007feec1788690 R9: 0x00007ffd9f27a8a0 R10: 0x00007feedc98dc08 R11: 0x0000000000000001 R12: 0x00007feedcf35049 R13: 0x0041710f058b48c3 R14: 0x0000562a51a61c20 R15: 0x000000000000008c EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /lib64/libruby.so.3.3(rb_print_backtrace+0x21) [0x7feedd078041] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_dump.c:820 /lib64/libruby.so.3.3(rb_vm_bugreport+0x9aa) [0x7feedd07adda] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_dump.c:1151 /lib64/libruby.so.3.3(rb_bug_for_fatal_signal+0x110) [0x7feedced5900] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/error.c:1065 /lib64/libruby.so.3.3(sigsegv+0x56) [0x7feedcfeef06] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/signal.c:920 /lib64/libc.so.6(__restore_rt+0x0) [0x7feedcc5b9a0] /lib64/libruby.so.3.3(rb_id_table_lookup+0x7) [0x7feedd015807] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/symbol.h:72 /lib64/libruby.so.3.3(vm_search_cc.lto_priv.0+0x58) [0x7feedd04dc58] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_insnhelper.c:2032 /lib64/libruby.so.3.3(vm_search_method_slowpath0.lto_priv.0+0x39) [0x7feedd04e0d9] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_insnhelper.c:2128 /lib64/libruby.so.3.3(vm_exec_core.lto_priv.0+0x4d7e) [0x7feedd062c1e] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm_insnhelper.c:2210 /lib64/libruby.so.3.3(rb_vm_exec+0x39e) [0x7feedd07665e] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/vm.c:2494 /lib64/libruby.so.3.3(rb_ec_exec_node+0xaa) [0x7feedcedb02a] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/eval.c:287 /lib64/libruby.so.3.3(ruby_run_node+0x93) [0x7feedcedba73] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/eval.c:328 /usr/bin/ruby-mri(0x562a5047f197) [0x562a5047f197] /lib64/libc.so.6(__libc_start_call_main+0x7a) [0x7feedcc4514a] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7feedcc4520b] /usr/bin/ruby-mri(_start+0x25) [0x562a5047f1e5] /usr/src/debug/ruby-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64/main.c:59 -- Other runtime information ----------------------------------------------- * Loaded script: foo.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /usr/lib64/ruby/enc/encdb.so 7 /usr/lib64/ruby/enc/trans/transdb.so 8 /usr/lib64/ruby/rbconfig.rb 9 /usr/share/rubygems/rubygems/compatibility.rb 10 /usr/share/rubygems/rubygems/defaults.rb 11 /usr/share/rubygems/rubygems/deprecate.rb 12 /usr/share/rubygems/rubygems/errors.rb 13 /usr/share/rubygems/rubygems/unknown_command_spell_checker.rb 14 /usr/share/rubygems/rubygems/exceptions.rb 15 /usr/share/rubygems/rubygems/basic_specification.rb 16 /usr/share/rubygems/rubygems/stub_specification.rb 17 /usr/share/rubygems/rubygems/platform.rb 18 /usr/share/rubygems/rubygems/util/list.rb 19 /usr/share/rubygems/rubygems/version.rb 20 /usr/share/rubygems/rubygems/requirement.rb 21 /usr/share/rubygems/rubygems/specification.rb 22 /usr/share/rubygems/rubygems/defaults/operating_system.rb 23 /usr/share/rubygems/rubygems/util.rb 24 /usr/share/rubygems/rubygems/dependency.rb 25 /usr/share/rubygems/rubygems/core_ext/kernel_gem.rb 26 /usr/lib64/ruby/monitor.so 27 /usr/share/ruby/monitor.rb 28 /usr/share/rubygems/rubygems.rb 29 /usr/share/ruby/bundled_gems.rb 30 /usr/share/rubygems/rubygems/path_support.rb 31 /usr/share/ruby/error_highlight/version.rb 32 /usr/share/ruby/error_highlight/base.rb 33 /usr/share/ruby/error_highlight/formatter.rb 34 /usr/share/ruby/error_highlight/core_ext.rb 35 /usr/share/ruby/error_highlight.rb 36 /usr/share/ruby/did_you_mean/version.rb 37 /usr/share/ruby/did_you_mean/core_ext/name_error.rb 38 /usr/share/ruby/did_you_mean/levenshtein.rb 39 /usr/share/ruby/did_you_mean/jaro_winkler.rb 40 /usr/share/ruby/did_you_mean/spell_checker.rb 41 /usr/share/ruby/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 42 /usr/share/ruby/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 43 /usr/share/ruby/did_you_mean/spell_checkers/name_error_checkers.rb 44 /usr/share/ruby/did_you_mean/spell_checkers/method_name_checker.rb 45 /usr/share/ruby/did_you_mean/spell_checkers/key_error_checker.rb 46 /usr/share/ruby/did_you_mean/spell_checkers/null_checker.rb 47 /usr/share/ruby/did_you_mean/tree_spell_checker.rb 48 /usr/share/ruby/did_you_mean/spell_checkers/require_path_checker.rb 49 /usr/share/ruby/did_you_mean/spell_checkers/pattern_key_name_checker.rb 50 /usr/share/ruby/did_you_mean/formatter.rb 51 /usr/share/ruby/did_you_mean.rb 52 /usr/share/ruby/syntax_suggest/core_ext.rb * Process memory map: 562a5047e000-562a5047f000 r--p 00000000 08:08 6739413 /usr/bin/ruby-mri 562a5047f000-562a50480000 r-xp 00001000 08:08 6739413 /usr/bin/ruby-mri 562a50480000-562a50481000 r--p 00002000 08:08 6739413 /usr/bin/ruby-mri 562a50481000-562a50482000 r--p 00002000 08:08 6739413 /usr/bin/ruby-mri 562a50482000-562a50483000 rw-p 00003000 08:08 6739413 /usr/bin/ruby-mri 562a51832000-562a51c68000 rw-p 00000000 00:00 0 [heap] 7feebc800000-7feebca51000 r--s 00000000 08:08 6732430 /usr/lib64/libc.so.6 7feebcc00000-7feebec0c000 r--s 00000000 08:08 6731115 /usr/lib/debug/usr/lib64/libruby.so.3.3.0-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feebee00000-7feec0e0c000 r--s 00000000 08:08 6731115 /usr/lib/debug/usr/lib64/libruby.so.3.3.0-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feec1000000-7feec1571000 r--s 00000000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feec15d0000-7feec15e0000 rw-p 00000000 00:00 0 7feec16f0000-7feec1700000 rw-p 00000000 00:00 0 7feec1760000-7feec17a0000 rw-p 00000000 00:00 0 7feec17b0000-7feec1870000 rw-p 00000000 00:00 0 7feec187a000-7feec187f000 r--s 00000000 08:08 6731114 /usr/lib/debug/usr/bin/ruby-mri-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feec187f000-7feec1880000 ---p 00000000 00:00 0 7feec1880000-7feec1921000 rw-p 00000000 00:00 0 7feec1921000-7feec1922000 ---p 00000000 00:00 0 7feec1922000-7feec19c3000 rw-p 00000000 00:00 0 7feec19c3000-7feec19c4000 ---p 00000000 00:00 0 7feec19c4000-7feec1a65000 rw-p 00000000 00:00 0 7feec1a65000-7feec1a66000 ---p 00000000 00:00 0 7feec1a66000-7feec1b07000 rw-p 00000000 00:00 0 7feec1b07000-7feec1b08000 ---p 00000000 00:00 0 7feec1b08000-7feec1ba9000 rw-p 00000000 00:00 0 7feec1ba9000-7feec1baa000 ---p 00000000 00:00 0 7feec1baa000-7feec1c4b000 rw-p 00000000 00:00 0 7feec1c4b000-7feec1c4c000 ---p 00000000 00:00 0 7feec1c4c000-7feec1ced000 rw-p 00000000 00:00 0 7feec1ced000-7feec1cee000 ---p 00000000 00:00 0 7feec1cee000-7feec1d8f000 rw-p 00000000 00:00 0 7feec1d8f000-7feec1d90000 ---p 00000000 00:00 0 7feec1d90000-7feec1e31000 rw-p 00000000 00:00 0 7feec1e31000-7feec1e32000 ---p 00000000 00:00 0 7feec1e32000-7feec1ed3000 rw-p 00000000 00:00 0 7feec1ed3000-7feec1ed4000 ---p 00000000 00:00 0 7feec1ed4000-7feec1f75000 rw-p 00000000 00:00 0 7feec1f75000-7feec1f76000 ---p 00000000 00:00 0 7feec1f76000-7feec2017000 rw-p 00000000 00:00 0 7feec2017000-7feec2018000 ---p 00000000 00:00 0 7feec2018000-7feec20b9000 rw-p 00000000 00:00 0 7feec20b9000-7feec20ba000 ---p 00000000 00:00 0 7feec20ba000-7feec215b000 rw-p 00000000 00:00 0 7feec215b000-7feec215c000 ---p 00000000 00:00 0 7feec215c000-7feec21fd000 rw-p 00000000 00:00 0 7feec21fd000-7feec21fe000 ---p 00000000 00:00 0 7feec21fe000-7feec229f000 rw-p 00000000 00:00 0 7feec229f000-7feec22a0000 ---p 00000000 00:00 0 7feec22a0000-7feec2341000 rw-p 00000000 00:00 0 7feec2341000-7feec2342000 ---p 00000000 00:00 0 7feec2342000-7feec23e3000 rw-p 00000000 00:00 0 7feec23e3000-7feec23e4000 ---p 00000000 00:00 0 7feec23e4000-7feec2485000 rw-p 00000000 00:00 0 7feec2485000-7feec2486000 ---p 00000000 00:00 0 7feec2486000-7feec2527000 rw-p 00000000 00:00 0 7feec2527000-7feec2528000 ---p 00000000 00:00 0 7feec2528000-7feec25c9000 rw-p 00000000 00:00 0 7feec25c9000-7feec25ca000 ---p 00000000 00:00 0 7feec25ca000-7feec266b000 rw-p 00000000 00:00 0 7feec266b000-7feec266c000 ---p 00000000 00:00 0 7feec266c000-7feec270d000 rw-p 00000000 00:00 0 7feec270d000-7feec270e000 ---p 00000000 00:00 0 7feec270e000-7feec27af000 rw-p 00000000 00:00 0 7feec27af000-7feec27b0000 ---p 00000000 00:00 0 7feec27b0000-7feec2851000 rw-p 00000000 00:00 0 7feec2851000-7feec2852000 ---p 00000000 00:00 0 7feec2852000-7feec28f3000 rw-p 00000000 00:00 0 7feec28f3000-7feec28f4000 ---p 00000000 00:00 0 7feec28f4000-7feec2995000 rw-p 00000000 00:00 0 7feec2995000-7feec2996000 ---p 00000000 00:00 0 7feec2996000-7feec2a37000 rw-p 00000000 00:00 0 7feec2a37000-7feec2a38000 ---p 00000000 00:00 0 7feec2a38000-7feec2ad9000 rw-p 00000000 00:00 0 7feec2ad9000-7feec2ada000 ---p 00000000 00:00 0 7feec2ada000-7feec2b7b000 rw-p 00000000 00:00 0 7feec2b7b000-7feec2b7c000 ---p 00000000 00:00 0 7feec2b7c000-7feec2c1d000 rw-p 00000000 00:00 0 7feec2c1d000-7feec2c1e000 ---p 00000000 00:00 0 7feec2c1e000-7feec2cbf000 rw-p 00000000 00:00 0 7feec2cbf000-7feec2cc0000 ---p 00000000 00:00 0 7feec2cc0000-7feec3510000 rw-p 00000000 00:00 0 7feec3511000-7feec3516000 r--s 00000000 08:08 6731114 /usr/lib/debug/usr/bin/ruby-mri-3.3.0~20231127.1146gita07d84b63c-184.fc40.327.x86_64.debug 7feec3516000-7feec351a000 r--s 00000000 08:08 6739413 /usr/bin/ruby-mri 7feec351a000-7feec351b000 r--p 00000000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351b000-7feec351c000 r-xp 00001000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351c000-7feec351d000 r--p 00002000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351d000-7feec351e000 r--p 00002000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351e000-7feec351f000 rw-p 00003000 08:08 7079696 /builddir/build/BUILD/swig-4.1.1/TEST/bar.so 7feec351f000-7feedc990000 rw-p 00000000 00:00 0 7feedc990000-7feedc991000 r--p 00000000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc991000-7feedc992000 r-xp 00001000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc992000-7feedc993000 r--p 00002000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc993000-7feedc994000 r--p 00002000 08:08 6738604 /usr/lib64/ruby/monitor.so 7feedc994000-7feedca96000 rw-p 00000000 00:00 0 7feedca96000-7feedcaa6000 r--p 00000000 08:08 6732433 /usr/lib64/libm.so.6 7feedcaa6000-7feedcb1c000 r-xp 00010000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb1c000-7feedcb76000 r--p 00086000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb76000-7feedcb77000 r--p 000df000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb77000-7feedcb78000 rw-p 000e0000 08:08 6732433 /usr/lib64/libm.so.6 7feedcb78000-7feedcb89000 r--p 00000000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcb89000-7feedcc05000 r-xp 00011000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc05000-7feedcc1a000 r--p 0008d000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc1a000-7feedcc1c000 r--p 000a1000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc1c000-7feedcc1d000 rw-p 000a3000 08:08 6732764 /usr/lib64/libgmp.so.10.4.1 7feedcc1d000-7feedcc43000 r--p 00000000 08:08 6732430 /usr/lib64/libc.so.6 7feedcc43000-7feedcda4000 r-xp 00026000 08:08 6732430 /usr/lib64/libc.so.6 7feedcda4000-7feedcdf2000 r--p 00187000 08:08 6732430 /usr/lib64/libc.so.6 7feedcdf2000-7feedcdf6000 r--p 001d4000 08:08 6732430 /usr/lib64/libc.so.6 7feedcdf6000-7feedcdf8000 rw-p 001d8000 08:08 6732430 /usr/lib64/libc.so.6 7feedcdf8000-7feedce00000 rw-p 00000000 00:00 0 7feedce00000-7feedce4a000 r--p 00000000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedce4a000-7feedd1c9000 r-xp 0004a000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd1c9000-7feedd334000 r--p 003c9000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd334000-7feedd34d000 r--p 00533000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd34d000-7feedd34e000 rw-p 0054c000 08:08 6731218 /usr/lib64/libruby.so.3.3.0 7feedd34e000-7feedd363000 rw-p 00000000 00:00 0 7feedd365000-7feedd368000 rw-p 00000000 00:00 0 7feedd368000-7feedd36b000 r--p 00000000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd36b000-7feedd386000 r-xp 00003000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd386000-7feedd38a000 r--p 0001e000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd38a000-7feedd38b000 r--p 00021000 08:08 6731236 /usr/lib64/libgcc_s-13-20231113.so.1 7feedd38b000-7feedd38e000 rw-p 00000000 00:00 0 7feedd38e000-7feedd390000 r--p 00000000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd390000-7feedd3a4000 r-xp 00002000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd3a4000-7feedd3bd000 r--p 00016000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd3bd000-7feedd3be000 r--p 0002e000 08:08 6732782 /usr/lib64/libcrypt.so.2.0.0 7feedd3be000-7feedd3c7000 rw-p 00000000 00:00 0 7feedd3c7000-7feedd3ca000 r--p 00000000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3ca000-7feedd3d9000 r-xp 00003000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3d9000-7feedd3df000 r--p 00012000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3df000-7feedd3e0000 r--p 00018000 08:08 6732659 /usr/lib64/libz.so.1.2.13 7feedd3e0000-7feedd3e3000 rw-p 00000000 00:00 0 7feedd3e3000-7feedd3e4000 r--p 00000000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e4000-7feedd3e5000 r-xp 00001000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e5000-7feedd3e6000 r--p 00002000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e6000-7feedd3e7000 r--p 00002000 08:08 6738584 /usr/lib64/ruby/enc/trans/transdb.so 7feedd3e7000-7feedd3e8000 rw-p 00000000 00:00 0 7feedd3e8000-7feedd3e9000 r--p 00000000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3e9000-7feedd3ea000 r-xp 00001000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3ea000-7feedd3eb000 r--p 00002000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3eb000-7feedd3ec000 r--p 00002000 08:08 6732495 /usr/lib64/ruby/enc/encdb.so 7feedd3ec000-7feedd3ed000 rw-p 00000000 00:00 0 7feedd3ed000-7feedd3ee000 r--p 00000000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd3ee000-7feedd415000 r-xp 00001000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd415000-7feedd41f000 r--p 00028000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd41f000-7feedd421000 r--p 00031000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7feedd421000-7feedd423000 rw-p 00033000 08:08 6732427 /usr/lib64/ld-linux-x86-64.so.2 7ffd9ea7e000-7ffd9f27d000 rw-p 00000000 00:00 0 [stack] 7ffd9f35d000-7ffd9f361000 r--p 00000000 00:00 0 [vvar] 7ffd9f361000-7ffd9f363000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] foofoo-test.sh: line 6: 141 Aborted (core dumped) ruby -I. foo.rb ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115485] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by vo.x (Vit Ondruch) 27 Nov '23

27 Nov '23

Issue #14582 has been updated by vo.x (Vit Ondruch). Yes, this si still the case. And it is [documented](https://github.com/ruby/ruby/pull/3115). Nevertheless, I don't think this is acceptable. The original DTrace probes implementation imposed nearly zero cost for runtime. Later it was somehow bound to TracePoint and now due to TracePoint being slow, the DTrace probes are disabled? Just reading the code, (I have not tested this snipped, but) would something like this help? ~~~diff $ git diff diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 9f9d0fcfd8..ee0a77e9fb 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -6489,7 +6489,6 @@ vm_trace_hook(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp, const VAL if (event & global_hooks->events) { /* increment PC because source line is calculated with PC-1 */ reg_cfp->pc++; - vm_dtrace(event, ec); rb_exec_event_hook_orig(ec, global_hooks, event, self, 0, 0, 0 , val, 0); reg_cfp->pc--; } @@ -6622,6 +6621,8 @@ vm_trace(rb_execution_context_t *ec, rb_control_frame_t *reg_cfp) vm_trace_hook(ec, reg_cfp, pc, RUBY_EVENT_RETURN, RUBY_EVENT_RETURN, global_hooks, bmethod_local_hooks_ptr, TOPN(0)); } + vm_dtrace(pc_events & RUBY_EVENT_CALL, ec); + // Pin the iseq since `local_hooks_ptr` points inside the iseq's slot on the GC heap. // We need the pointer to stay valid in case compaction happens in a trace hook. // ~~~ ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-105415 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * Priority: Normal * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115346] [Ruby master Bug#20001] Make Ruby work properly with ASAN enabled
by kjtsanaktsidis (KJ Tsanaktsidis) 27 Nov '23

27 Nov '23

Issue #20001 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20001: Make Ruby work properly with ASAN enabled https://bugs.ruby-lang.org/issues/20001 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This ticket covers some work I want to do to get the ASAN infrastructure working in Ruby working again. I don't know if it ever worked well, but if it did, it appears to have bitrotted. Here are a few of its current problems: ### Stack size calculations are wrong Ruby takes the address of a local variable as part of the process of working out the top/bottom of the native stack in `native_thread_init_stack`. Because ASAN can end up putting some local variables on a "fake stack", this calculation can wind up producing the wrong result and setting `th->ec->machine.stack_start` incorrectly. This then leads to `stack_check` thinking that the machine stack has overflowed all the time, and thus, leading to programs like the following to fail: ``` ASAN_OPTIONS=use_sigaltstack=0:detect_leaks=0 ./miniruby -e 'Thread.new { puts "hi" }.join' #<Thread:0x00007fb5d79f3f28 -e:1 run> terminated with exception (report_on_exception is true): SystemStackError -e: stack level too deep (SystemStackError) ``` Another consequence of stack size detection not working properly is that the machine stack is not properly marked during GC, so things on the stack which should be considered live get prematurely collected. ASAN provides the `__asan_addr_is_in_fake_stack` function which can be used to get the address of a local variable on the real stack; I think Ruby's various stack-detecting macros could then make use of this to make it work. ### VALUEs in fake stacks are not marked Another consequece of ASAN storing local variables in fake stacks is that we don't see them when doing the machine stack mark. Again, the `__asan_addr_is_in_fake_stack` function can help us here. ASAN leaves a pointer to the fake stack on the real stack in every frame. When marking the machine stack, we can check each word to see if it's a pointer to a fake stack frame, and then use `__asan_addr_is_in_fake_stack` to get the extents of the fake frame and scan that too. This seems to be e.g. [how V8 does it](https://github.com/v8/v8/blob/1c7d3a94fc051e0fd69584b930faab448026941e/… ### Doesn't work with GCC Our ASAN implementation doesn't work with GCC, even though GCC supports ASAN. This is because we use the `__has_feature(address_sanitizer)` macro in sanitizers.h, which is a clang-ism. The equivalent GCCism is `__SANITIZE_ADDRESS__` and we should check that too. ## Plan of attack At the moment, I can't even run a full build of ruby to run, because miniruby crashees during the build process. My plan of attack here is to: * Address those known problems I've already identified above * Get `make` to actually work with asan * Try running the test suite through ASAN, and fix any issues that turns up * I'm thinking we should add an `--enable-asan` or `--enable-address-sanitizer` or some such to our configure script, to make it easy to build Ruby with ASAN without having to poke around with individual CFLAGS/LDFLAGS * Eventually, it would be great to actually run the tests under ASAN in CI This is probably a medium term body of work, but I'll try and tackle it in bits. Also: @HParker and @peterzhu2118 - I know you folks have been working on getting Valgrind to work better with Ruby, for leak detection. I _think_ I see my efforts here as complementary to yours, rather than duplicative. The ASAN infrastructure for poisoning/unpoisoning stuff in the GC already exists and is _close_ to working properly, and it really did help me solve a bug yesterday (https://bugs.ruby-lang.org/issues/19994) so it seems useful and should be made to work. Your work on freeing memory on shutdown (https://bugs.ruby-lang.org/issues/19993) should actually help ASAN usefully detect leaks as well. I think ASAN might be better for eventually running CI checks against the full Ruby test suite, since allegedly it's faster. However, if you think solving these issues with ASAN is a waste of time and Valgrind can catch the same bugs already, please chime in! -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115480] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 26 Nov '23

26 Nov '23

Issue #18368 has been updated by zverok (Victor Shepelev). I am sorry that only now I had time to further work on the feature. I understand it is almost Decemeber and the feature might not make it in the 3.3 (though I would be happy if it would). The generic backward iteration was implemented: ```ruby (Time.utc(2022, 3, 1)..Time.utc(2022, 2, 24)).step(-24*60*60) { puts _1 } # Prints: # 2022-03-01 00:00:00 UTC # 2022-02-28 00:00:00 UTC # 2022-02-27 00:00:00 UTC # 2022-02-26 00:00:00 UTC # 2022-02-25 00:00:00 UTC # 2022-02-24 00:00:00 UTC ``` The coercion for numeric values and custom objects works as expected: ```ruby val = Struct.new(:val) do def coerce(num) = [num, val] end p (1..3).step(val.new(1)).to_a # => [1, 2, 3] ``` So I believe the feature is ready for the final review/merge. Two nuances I am currently aware of: **1. I didn't change the behavior of numeric iteration, but it might be considered inconsistent:** ```ruby (1r..).step(1).take(3) #=> [(1/1), 2.0, 3.0] (1r..).step(1.0).take(3) #=> [1.0, 2.0, 3.0] ``` One might expect that those examples would return `[1r, 2r, 3r]`, but **that's how it always worked**. **2. The `rbs` tests are [broken](https://github.com/ruby/ruby/actions/runs/6994686558/job/1902872834… That's not because the RBS itself is broken by the change, but because one of the tests [uses](https://github.com/ruby/rbs/blob/master/test/stdlib/Range_test.rb#L10… string range with the default and numeric steps, which are now incorrect. I don't think it represents some realistic use case, and RBS tests should be fixed. I will be grateful for the instruction how to do that (I mean, what's the process to adjust bundled gem's tests that became irrelevant for the new Ruby version). ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-105411 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories
by vo.x (Vit Ondruch) 24 Nov '23

24 Nov '23

Issue #19972 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19972: Install default/bundled gems into dedicated directories https://bugs.ruby-lang.org/issues/19972 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-24 master c44d65427e) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I think that the current situation, where the same directory (lets call it `Gem.default_dir`) is used for default/bundled gems as well as for user installed gems, is suboptimal. During the times, this has caused us quite some issue on Fedora. Historically, we redefined the `Gem.default_dir` to user home directory, to avoid the mixing of system gems and user installed gems. Unfortunately, with advent of default/bundled gems, we were facing issues that these gems were suddenly not listed, etc. I am realizing this issue in full once again since the "user install" RubyGems feature has landed [1]. I also think that we have arrived to this situation by evolution, not by design. Therefore my proposal is: Keep the `Gem.default_dir` for user `gem install`ed gems and lets install default and bundled gems into separate dedicated directories. Have separate `Gem.bundled_gems_dir` and `Gem.default_gems_dir` structures. Of course, if `Gem.default_dir == Gem.bundled_gems_dir == Gem.default_gems_dir`, we still can have the current layout. I have a simple POC here: https://github.com/ruby/ruby/pull/8761 BTW I have reported it here, because I think that RubyGems provides all it is needed. So it is not RubyGems ticket after all. However, I believe that RubyGems could benefit from this long term and some simplifications/cleanups would be possible. [1]: https://github.com/rubygems/rubygems/pull/5327 -- https://bugs.ruby-lang.org/

6 10

[ruby-core:115466] [Ruby master Bug#20020] Segfault running regexp match?
by andrea.salicetti＠gmail.com (Andrea Salicetti) 24 Nov '23

24 Nov '23

Issue #20020 has been reported by andrea.salicetti(a)gmail.com (Andrea Salicetti). ---------------------------------------- Bug #20020: Segfault running regexp match? https://bugs.ruby-lang.org/issues/20020 * Author: andrea.salicetti(a)gmail.com (Andrea Salicetti) * Status: Open * Priority: Normal * ruby -v: 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- **Ruby version** : ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin23] From `irb`, trying to call `match?` on this regular expression causes a segmentation falut: ```ruby irb(main):001:0> /^((a|c)|\s?){1,3}$/.match?('abc') => false irb(main):002:0> /^((a|c)|\s?){1,3}$/.match?('abc') (irb):2: [BUG] Segmentation fault at 0x000000061ba998e8 ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-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:0037 p:---- s:0207 e:000206 CFUNC :match? c:0036 p:0006 s:0202 e:000201 EVAL (irb):2 [FINISH] c:0035 p:---- s:0199 e:000198 CFUNC :eval c:0034 p:0020 s:0191 e:000190 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/workspace.rb:119 c:0033 p:0153 s:0183 e:000181 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/context.rb:502 c:0032 p:0119 s:0170 e:000169 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:588 c:0031 p:0024 s:0164 e:000163 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:777 c:0030 p:0007 s:0158 e:000157 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:567 c:0029 p:0126 s:0153 e:000152 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:267 [FINISH] c:0028 p:---- s:0149 e:000148 CFUNC :loop c:0027 p:0005 s:0145 e:000144 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:249 [FINISH] c:0026 p:---- s:0142 e:000141 CFUNC :catch c:0025 p:0010 s:0137 e:000136 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb/ruby-lex.rb:248 c:0024 p:0050 s:0132 E:000dd8 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:566 c:0023 p:0003 s:0127 e:000126 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:500 [FINISH] c:0022 p:---- s:0124 e:000123 CFUNC :catch c:0021 p:0050 s:0119 E:000d50 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:499 c:0020 p:0069 s:0113 e:000112 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/3.2.0/irb.rb:421 c:0019 p:0012 s:0107 e:000106 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11 [FINISH] c:0018 p:---- s:0104 e:000103 CFUNC :load c:0017 p:0078 s:0099 e:000098 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/bin/irb:25 [FINISH] c:0016 p:---- s:0094 e:000093 CFUNC :load c:0015 p:0064 s:0089 e:000088 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:58 c:0014 p:0050 s:0083 e:000082 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:23 c:0013 p:0034 s:0078 e:000077 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:492 c:0012 p:0054 s:0073 e:000072 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:28 c:0011 p:0040 s:0065 e:000064 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127 c:0010 p:0213 s:0058 e:000057 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:527 c:0009 p:0008 s:0045 e:000044 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:34 c:0008 p:0044 s:0040 e:000039 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:584 c:0007 p:0022 s:0033 e:000032 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:28 c:0006 p:0042 s:0028 e:000027 BLOCK /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.22/exe/bundle:37 c:0005 p:0007 s:0022 e:000021 METHOD /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/site_ruby/3.2.0/bundler/friendly_errors.rb:117 c:0004 p:0108 s:0017 E:0019b8 TOP /Users/andreasalicetti/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.4.22/exe/bundle:29 [FINISH] c:0003 p:---- s:0013 e:000012 CFUNC :load c:0002 p:0081 s:0008 E:000220 EVAL /Users/andreasalicetti/.rbenv/versions/3.2.2/bin/bundle:25 [FINISH] c:0001 p:0000 s:0003 E:001980 DUMMY [FINISH] ``` Sometimes this happens the very first time I try to execute the command, some other times I have to try a couple of times to see that Segmentation Fault (but usually within the first 5 attempts). ---Files-------------------------------- ruby-2023-11-23-175410.ips (20.2 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:115465] [Ruby master Bug#20019] Ruby 3.3 GVL instrumentation events are fired out of order
by jpcamara (JP Camara) 23 Nov '23

23 Nov '23

Issue #20019 has been reported by jpcamara (JP Camara). ---------------------------------------- Bug #20019: Ruby 3.3 GVL instrumentation events are fired out of order https://bugs.ruby-lang.org/issues/20019 * Author: jpcamara (JP Camara) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-23T14:39:30Z fix-thread-instrum.. 285a41d793) +MN [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The order of instrumentation events is incorrect, and inconsistent with Ruby 3.2 ordering. You can find a spec to reproduce the broken behavior here: https://github.com/ruby/ruby/pull/9019. ### Steps to reproduce 1. Pull down this PR: https://github.com/ruby/ruby/pull/9019 2. Run `make test-all TESTS="../test/-ext-/thread/test_instrumentation_api.rb --name=TestThreadInstrumentation#test_order_of_events"` 3. Run `RUBY_MN_THREADS=1 make test-all TESTS="../test/-ext-/thread/test_instrumentation_api.rb --name=TestThreadInstrumentation#test_order_of_events"` ### Expected behavior It should pass the spec, and the events for each thread should match the array `%w[started ready resumed suspended exited]`. That is the consistent behavior on Ruby 3.2. ### Actual behavior When running `make test-all TESTS="../test/-ext-/thread/test_instrumentation_api.rb --name=TestThreadInstrumentation#test_order_of_events"`, the array of events is `%w[ready resumed started exited suspended]`. When running with `RUBY_MN_THREADS=1`, the array of events is `%w[ready started exited suspended]`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115463] [Ruby master Bug#17807] "Segmentation fault at 0x0000000000000008" crash when accessing instance variables of Process::Waiter instances (Ruby 2.3 to 2.6)
by ivoanjo (Ivo Anjo) 23 Nov '23

23 Nov '23

Issue #17807 has been updated by ivoanjo (Ivo Anjo). Randomly, I found today that right around when I was trying to debug this, the puma folks also independently ran into it: https://github.com/puma/puma/issues/2566 ---------------------------------------- Bug #17807: "Segmentation fault at 0x0000000000000008" crash when accessing instance variables of Process::Waiter instances (Ruby 2.3 to 2.6) https://bugs.ruby-lang.org/issues/17807#change-105391 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal * ruby -v: ruby 2.6.7p197 (2021-04-05 revision 67941) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Hey there! I'm in [Datadog's ddtrace gem](https://github.com/DataDog/dd-trace-rb) team and one of our customers was running into this crash. Reproducing it is trivial: `ruby -e 'Process.detach(fork {}); Thread.list.last.instance_variable_get(:@kaboom)'`. The issue seems to be that some of the internal structures of the `Process::Waiter` are not properly initialized, and so trying to access instance variables on an instance of that very special class triggers the crash. This seems to affect Ruby from 2.3 up to 2.6, on both Linux and macOS. I've attached a crash log, but probably running the reproducer example is faster :) As I said above, this crash is gone on 2.7 and 3.0. I could not find any mention of this crash, so I suspect the fix may have been a happy side effect of some refactoring, rather than a deliberate thing. Furthermore, I know that out of the affected versions, only 2.6 is the only one still not EOL, and I am not sure if this can be qualified as a security issue. I decided to report it anyway, in the spirit of documenting what I learned. Feel free to close the ticket if indeed there's no plans of fixing it. Finally, here's some hints, if someone out there also needs to work around this issue: * `defined?` (from inside the class) or `instance_variable_defined?` (from the outside) seem to work, so if you "look before you jump", you can avoid the crash * Writing once to any instance variable on any instance of a `Process::Waiter` seems to initialize whatever was missing; afterwards, any instance of this class will behave correctly * You can always check the `.class` of the thread to see if you should skip whatever you were trying to do with it ---Files-------------------------------- crash-log.txt (16 KB) -- https://bugs.ruby-lang.org/

1 0