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

[ruby-core:119201] [Ruby master Bug#20743] ruby doesn't properly split RUBY_DEBUG_LOG_FILTER into items
by x-yuri (Yuri Kanivetsky) 28 Jan '25

28 Jan '25

Issue #20743 has been reported by x-yuri (Yuri Kanivetsky). ---------------------------------------- Bug #20743: ruby doesn't properly split RUBY_DEBUG_LOG_FILTER into items https://bugs.ruby-lang.org/issues/20743 * Author: x-yuri (Yuri Kanivetsky) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-15T01:06:11Z master 532af89e3b) +PRISM [x86_64-linux-musl] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` $ docker run --rm alpine:3.20.3 sh -euxc ' apk add git build-base autoconf ruby yaml-dev zlib-dev openssl-dev libffi-dev git clone https://github.com/ruby/ruby cd ruby git checkout 532af89e3b5b78dd3a6fe29c6cc64ad1b073afe2 ./autogen.sh ./configure cflags=-DUSE_RUBY_DEBUG_LOG --disable-install-doc make -j8 install ruby -v RUBY_DEBUG_LOG=stderr RUBY_DEBUG_LOG_FILTER=rb_thread_schedule_limits,rb_ractor_thread_switch ruby -e "" ' ... + RUBY_DEBUG_LOG=stderr RUBY_DEBUG_LOG_FILTER=rb_thread_schedule_limits,rb_ractor_thread_switch ruby -e RUBY_DEBUG_LOG=stderr [stderr] RUBY_DEBUG_LOG_FILTER[0]=rb_thread_schedule_limit (all) RUBY_DEBUG_LOG_FILTER[1]=rb_ractor_thread_switch (all) ... ``` As you can see `ruby` reports that `RUBY_DEBUG_LOG_FILTER[0]` equals `rb_thread_schedule_limit`, not `rb_thread_schedule_limits`. This happens because here: https://github.com/ruby/ruby/blob/532af89e3b5b78dd3a6fe29c6cc64ad1b073afe2/… `1` should not be subtracted. Also in the following lines `str` is increased, but `len` is not decreased. It makes sense to recheck if there are no further mistakes. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118879] [Ruby master Bug#20682] Slave PTY output is lost after a child process exits in macOS
by ono-max (Naoto Ono) 27 Jan '25

27 Jan '25

Issue #20682 has been reported by ono-max (Naoto Ono). ---------------------------------------- Bug #20682: Slave PTY output is lost after a child process exits in macOS https://bugs.ruby-lang.org/issues/20682 * Author: ono-max (Naoto Ono) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- According to Launchable, the following PTY tests are flaky only on macOS. https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… https://app.launchableinc.com/organizations/ruby/workspaces/ruby/data/test-… It's because the slave PTY output is lost after a child process exits in macOS. Here is the code to reproduce the problem. When I remove `sleep 3` from the code, "a" is returned. ``` require 'pty' r, w, pid = PTY.spawn('ruby', '-e', 'puts "a"') sleep 3 puts r.gets #=> Returns nil ``` Based on my investigation, this issue happens in the macOS side and it's almost same as https://github.com/pexpect/pexpect/issues/662. The cause is described as follows in the ticket: > // NOTE[macOS-S_CTTYREF]: On macOS, after a forkpty(), if the pty slave (child) // is closed before the pty master (parent) reads, the pty's buffer is cleared // thus the master (parent) reads nothing. This can happen if the child exits // before the parent has a chance to call master.read(). // // This issue has been reported to Apple, but has not been resolved: // https://developer.apple.com/forums/thread/663632 // // Work around this issue by opening /dev/tty then closing it. This ultimately // causes the child's exit() to flush the slave pty's output buffer in a // blocking way. This fixes the problem on macOS 13.2 in my testing. // // Here's how the workaround works in detail: // // If we open /dev/tty, it sets the S_CTTYREF flag on the process. This flag // remains set if we close the /dev/tty file descriptor. // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // Additionally, opening /dev/tty retains a reference to the pty slave. // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // // When the child process exits: // // 1. All open file descriptors (including stdin/stdout/stderr which are the pty // slave) are closed. This does *not* drain unread pty slave output. // * If S_CTTYREF was set, closing the file descriptors does not close the // last reference to the pty slave, so no cleanup happens yet. // * NOTE[macOS-pty-close-loss]: If S_CTTYREF was not set, closing the file // descriptors drops the last reference to the pty slave. Unread data is // dropped. // // 2. If the S_CTTYREF flag is set on the child process, the controlling // terminal (pty slave) is closed. XNU's ptsclose() ultimately calls // ttywait(). // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // * ttywait() is the same as ioctl(slave, TIOCDRAIN); it blocks waiting for // output to be received. // https://github.com/apple-oss-distributions/xnu/blob/aca3beaa3dfbd42498b42c5… // * NOTE[macOS-pty-waitpid-hang]: Because of the blocking ttywait(), the // process is in an exiting (but not zombie) state. waitpid() will hang. // // * NOTE[macOS-pty-close-loss]: If the S_CTTYREF flag is not set on the // child process, ttywait() is not called, thus the pty slave does not // block waiting for the output to be received, and the output is dropped. // A well-behaving parent will use a poll() loop anyway, so this isn't a // problem. (It does make quick tests annoying to write though.) // // Demonstration of NOTE[macOS-pty-close-loss] (S_CTTYREF is not set before // exit): // // // On macOS, this program should report 'data = ""', demonstrating that // // writes are lost. // // #include <stdlib.h> // #include <errno.h> // #include <stdio.h> // #include <string.h> // #include <unistd.h> // #include <util.h> // // int main() { // int tty_fd; // pid_t pid = forkpty(&tty_fd, /*name=*/NULL, /*termp=*/NULL, // /*winp=*/NULL); // if (pid == -1) { perror("forkpty"); abort(); } // // if (pid == 0) { // // Child. // (void)write(STDOUT_FILENO, "y", 1); // exit(0); // } else { // // Parent. // // // Cause the child to write() then exit(). exit() will drop written // // data. // sleep(1); // // char buffer[10]; // ssize_t rc = read(tty_fd, buffer, sizeof(buffer)); // if (rc < 0) { perror("read"); abort(); } // fprintf(stderr, "data = \"%.*s\"\n", (int)rc, buffer); // } // // return 0; // } // // Demonstration of NOTE[macOS-pty-waitpid-hang] (S_CTTYREF is set before exit): // // // On macOS, this program should hang, demonstrating that the child // // process doesn't finish exiting. // // // // During the hang, observe that the child is in an exiting state ("E"): // // // // $ ps -e -o pid,stat | grep 20125 // // 20125 ?Es // // #include <errno.h> // #include <fcntl.h> // #include <stdio.h> // #include <stdlib.h> // #include <string.h> // #include <unistd.h> // #include <util.h> // // int main() { // int tty_fd; // pid_t pid = forkpty(&tty_fd, /*name=*/NULL, /*termp=*/NULL, // /*winp=*/NULL); // if (pid == -1) { perror("forkpty"); abort(); } // // if (pid == 0) { // // Child. // close(open("/dev/tty", O_WRONLY)); // (void)write(STDOUT_FILENO, "y", 1); // exit(0); // } else { // // Parent. // // fprintf(stderr, "child PID: %d\n", pid); // // // This will hang because, despite the child being is an exiting // // state, the child is waiting for us to read(). // pid_t rc = waitpid(pid, NULL, 0); // if (rc < 0) { perror("waitpid"); abort(); } // } // // return 0; // } In Ruby, PTY is implemented with [fork()](https://github.com/ruby/ruby/blob/master/process.c#L1706) and [posix_openpt()](https://github.com/ruby/ruby/blob/master/ext/pty/pty.c#L329) in macOS. I could reproduce the problem in the following script. ``` #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/ioctl.h> int main() { int master_fd, slave_fd; pid_t child_pid; char *slave_name; // Open a master pseudo-terminal master_fd = posix_openpt(O_RDWR | O_NOCTTY); if (master_fd == -1) { perror("posix_openpt"); exit(1); } // Grant access to the slave pseudo-terminal if (grantpt(master_fd) == -1) { perror("grantpt"); exit(1); } // Unlock the slave pseudo-terminal if (unlockpt(master_fd) == -1) { perror("unlockpt"); exit(1); } // Get the name of the slave pseudo-terminal slave_name = ptsname(master_fd); if (slave_name == NULL) { perror("ptsname"); exit(1); } // Fork a child process child_pid = fork(); if (child_pid == -1) { perror("fork"); exit(1); } else if (child_pid == 0) { // Child process // Open the slave pseudo-terminal slave_fd = open(slave_name, O_RDWR); if (slave_fd == -1) { perror("open"); exit(1); } // Create a new session and process group if (setsid() == -1) { perror("setsid"); exit(1); } // Set the controlling terminal for the child process if (ioctl(slave_fd, TIOCSCTTY, NULL) == -1) { perror("ioctl"); exit(1); } // Duplicate the slave file descriptor to stdin, stdout, and stderr if (dup2(slave_fd, STDIN_FILENO) == -1) { perror("dup2"); exit(1); } if (dup2(slave_fd, STDOUT_FILENO) == -1) { perror("dup2"); exit(1); } if (dup2(slave_fd, STDERR_FILENO) == -1) { perror("dup2"); exit(1); } // close(open("/dev/tty", O_WRONLY)); // Close the original slave file descriptor close(slave_fd); // Execute a shell or other program (void)write(STDOUT_FILENO, "y", 1); exit(1); } else { sleep(5); char buffer[10]; ssize_t rc = read(master_fd, buffer, sizeof(buffer)); if (rc < 0) { perror("read"); abort(); } fprintf(stderr, "data = \"%.*s\"\n", (int)rc, buffer); // Clean up close(master_fd); } return 0; } ``` -- https://bugs.ruby-lang.org/

3 8

[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:120303] [Ruby master Bug#20965] `it` vs `binding.local_variables`
by zverok (Victor Shepelev) 20 Jan '25

20 Jan '25

Issue #20965 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20965: `it` vs `binding.local_variables` https://bugs.ruby-lang.org/issues/20965 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- `it` is not available in the list of `binding.local_varaibles`, **unlike** numbered parameters: ```ruby p(proc { binding.local_variables }.call) # [] p(proc { |x| binding.local_variables }.call) # [:x] p(proc { _1; binding.local_variables }.call) # [:_1] p(proc { vars = binding.local_variables; _1; vars }.call) # [:_1, :vars] p(proc { it; binding.local_variables }.call) # [] ``` I wonder if it is deliberate or accidental. -- https://bugs.ruby-lang.org/

6 9

[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:120223] [Ruby master Bug#20950] Use-after-free in ep in Proc#dup for ifunc procs
by peterzhu2118 (Peter Zhu) 15 Jan '25

15 Jan '25

Issue #20950 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20950: Use-after-free in ep in Proc#dup for ifunc procs https://bugs.ruby-lang.org/issues/20950 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/12319 ifunc proc has the ep allocated in the data of the TypedData object. If an ifunc proc is duplicated, the ep points to the ep of the source object. If the source object is freed, then the ep of the duplicated object now points to a freed memory region. If we try to use the ep we could crash. For example, the following script crashes: ```ruby p = { a: 1 }.to_proc 100.times do p = p.dup GC.start p.call rescue ArgumentError end ``` This commit changes ifunc proc to also duplicate the ep when it is duplicated. -- https://bugs.ruby-lang.org/

3 2

[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