January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120797] [Ruby master Bug#21091] recursive require not detected on case insensitive filesystem
by rrotter (Ryan Rotter) 27 Jan '25

27 Jan '25

Issue #21091 has been reported by rrotter (Ryan Rotter). ---------------------------------------- Bug #21091: recursive require not detected on case insensitive filesystem https://bugs.ruby-lang.org/issues/21091 * Author: rrotter (Ryan Rotter) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On case insensitive filesystems `require`ing a file from itself causes the file to be `require`d twice if the initial `require` and the `require` inside the file have different capitalization. I expect the second `require` to return false, and not execute the file a second time. ``` ~ % cat /tmp/foo.rb puts "loading #{__FILE__}" require "/tmp/foo" SOME_GLOBAL = "foobar".freeze ~ % ruby -r/tmp/FOO loading /tmp/FOO.rb loading /tmp/foo.rb /tmp/FOO.rb:3: warning: already initialized constant SOME_GLOBAL /tmp/foo.rb:3: warning: previous definition of SOME_GLOBAL was here ``` This is on macOS 15.1.1, using the default case-insensitive APFS, and ruby 3.4.1. -- https://bugs.ruby-lang.org/

2 2

[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:120794] [Ruby master Bug#21089] Missing methods on enumerators created from Enumerator::product and Enumerator::Chain
by zetter (Chris Zetter) 27 Jan '25

27 Jan '25

Issue #21089 has been reported by zetter (Chris Zetter). ---------------------------------------- Bug #21089: Missing methods on enumerators created from Enumerator::product and Enumerator::Chain https://bugs.ruby-lang.org/issues/21089 * Author: zetter (Chris Zetter) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-26T08:52:22Z master d4a1a2780c) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I was using `Enumerator.product` and noticed the enumerators it returned were missing the `next` method. When looking at the source code, I saw all the stateful enumerator methods were missing (`next`, `peek_values`, `peek`, `next_values`, `feed`) as they were removed from the `Enumerator::Product` subclass with `rb_undef_method`. This also applies to instances of `Enumerator::Chain`, it looks like the methods never worked and were removed in https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/68… Because the English documentation says `Enumerator.product` 'Generates a new enumerator object' and the documentation says it inherits from `Enumerator` I expected it to have the `next` method available. I can use `.to_enum` to make the next method available, but I'm not sure why I need to. I'm unsure if this could be solved by making these available or the documentation could be improved. -- https://bugs.ruby-lang.org/

2 1

[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:120748] [Ruby master Bug#21083] current SystemCallError.new(-1) behavior on windows is not in accordance with the intent of the source code.
by YO4 (Yoshinao Muramatsu) 23 Jan '25

23 Jan '25

Issue #21083 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21083: current SystemCallError.new(-1) behavior on windows is not in accordance with the intent of the source code. https://bugs.ruby-lang.org/issues/21083 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- spec/ruby/core/exception/system_call_error_spec.rb says ``` platform_is :windows do SystemCallError.new(-1).message.should == "The operation completed successfully." end ``` but source code says ```if (e < 0) e = GetLastError();``` at win32/win32.c(2838,9) [1] So it appears that the intent is to retrieve previous errors. This is not what the spec intended. It seems that at some point the behavior was broken because the WIN32API TlsGetValue() sets LastError even if it succeeds. SystemCallError.new(-1).errno returns -1 instead of GetLastError() returns, so the current behavior is not very useful. In my opinion, it is preferable to return "Unknown Error #{e}" as on other platforms. This change needs to revert ruby/spec@328ac37 [2] [1] https://github.com/ruby/ruby/blob/2b1db0faecf03d3fa1b7a1b102cc4c51aa962d5f/… [2] https://github.com/ruby/spec/commit/328ac37 BACKGROUND I state the situation because I may be wrong in my guess. I was trying to make changes to allow Language TLS to be used on Windows, but found this spec fails. ``` 1) SystemCallError.new sets an 'unknown error' message when an unknown error number FAILED Expected "The system cannot find message text for message number 0x%1 in the message file for %2." == "The operation completed successfully." to be truthy but was false D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:104:in 'block (3 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:103:in 'block (2 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:22:in '<top (required)>' 2) SystemCallError.new adds a custom error message to an 'unknown error' message when an unknown error number and a custom message specified FAILED Expected "The system cannot find the path specified. - custom message" == "The operation completed successfully. - custom message" to be truthy but was false D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:114:in 'block (3 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:113:in 'block (2 levels) in <top (required)>' D:/a/ruby/ruby/src/spec/ruby/core/exception/system_call_error_spec.rb:22:in '<top (required)>' ``` message 1) because the previous execution of SystemCallError.new(2**24) failed to retrieve the message. MinGW(UCRT64) and VS2022 got same but VS2015 and VS2019 got different message "The resource loader cache doesn't have loaded MUI entry." message 2) I am not sure where this message was obtained from. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120765] [Ruby master Feature#21086] Declare rb_profile_frames() family as async-signal-safe
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #21086 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21086: Declare rb_profile_frames() family as async-signal-safe https://bugs.ruby-lang.org/issues/21086 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- Since @ivoanjo 's change in https://github.com/ruby/ruby/pull/11036 , I believe `rb_profile_frames()` and `rb_profile_thread_frames()` could be marked as async-signal-safe. I remember @ko1 had a few reasons not to do so. I'd like to ask what @ko1 thinks now. -- https://bugs.ruby-lang.org/

1 1

[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:120715] [Ruby master Bug#21045] [patch & workaround] "make test-all" failed with FreeBSD 13.4
by hs (Hideki Sakamoto) 20 Jan '25

20 Jan '25

Issue #21045 has been reported by hs (Hideki Sakamoto). ---------------------------------------- Bug #21045: [patch & workaround] "make test-all" failed with FreeBSD 13.4 https://bugs.ruby-lang.org/issues/21045 * Author: hs (Hideki Sakamoto) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- "make test-all" fails when building Ruby 3.4.1 on FreeBSD 13.4. Build and test steps: <pre> % freebsd-version 13.4-RELEASE-p2 % tar xf ruby-3.4.1.tar.xz % cd ruby-3.4.1/ % ./configure % make % make test-all (snip) 1) Error: TestNetHTTPForceEncoding#test_response_body_encoding_encoding_without_content_type: Errno::ECONNREFUSED: Failed to open TCP connection to localhost:34716 (Connection refused - connect(2) for "localhost" port 34716) /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'TCPSocket#initialize' /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'IO.open' /tmp/ruby-3.4.1/lib/net/http.rb:1659:in 'block in Net::HTTP#connect' /tmp/ruby-3.4.1/lib/timeout.rb:185:in 'block in Timeout.timeout' /tmp/ruby-3.4.1/lib/timeout.rb:192:in 'Timeout.timeout' /tmp/ruby-3.4.1/lib/net/http.rb:1657:in 'Net::HTTP#connect' /tmp/ruby-3.4.1/lib/net/http.rb:1636:in 'Net::HTTP#do_start' /tmp/ruby-3.4.1/lib/net/http.rb:1625:in 'Net::HTTP#start' /tmp/ruby-3.4.1/lib/net/http.rb:2369:in 'Net::HTTP#request' /tmp/ruby-3.4.1/lib/net/http.rb:1984:in 'Net::HTTP#get' /tmp/ruby-3.4.1/test/net/http/test_http.rb:1344:in 'TestNetHTTPForceEncoding#fe_request' /tmp/ruby-3.4.1/test/net/http/test_http.rb:1372:in 'TestNetHTTPForceEncoding#test_response_body_encoding_encoding_without_content_type' (snip) Finished tests in 672.429322s, 47.6734 tests/s, 9743.0849 assertions/s. 32057 tests, 6551536 assertions, 0 failures, 7 errors, 192 skips ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-freebsd13.4] *** Error code 7 </pre> ### 1. Seven tests in test/net/http/test_http.rb error with "(Connection refused - connect(2) for "localhost" port #####)" These errors appear to be caused by the client in function "fe_request"( **test/net/http/test_http.rb** ) trying to connect to IPv4 ('127.0.0.1') address: <pre> 1324 CONFIG = { * 1325 'host' => 'localhost', 1326 'proxy_host' => nil, 1327 'proxy_port' => nil, 1328 } 1329 1330 include TestNetHTTPUtils 1331 1332 def fe_request(force_enc, content_type=nil) 1333 @server.mount_proc('/fe') do |req, res| 1334 res['Content-Type'] = content_type if content_type 1335 res.body = "hello\u1234" 1336 end 1337 * 1338 http = Net::HTTP.new(config('host'), config('port')) 1339 http.local_host = Addrinfo.tcp(config('host'), config('port')).ip_address 1340 assert_not_nil(http.local_host) 1341 assert_nil(http.local_port) 1342 1343 http.response_body_encoding = force_enc 1344 http.get('/fe') 1345 end </pre> while the @server on line 12 of **test/net/http/utils.rb** listens on a socket with an IPv6 address (':: 1') when tested with ' **localhost** '. <pre> 9 class HTTPServer 10 def initialize(config, &block) 11 @config = config * 12 @server = TCPServer.new(@config['host'], 0) 13 @port = @server.addr[1] 14 @procs = {} </pre> I wasn't sure if this was a bug to fix. As a workaround, remove the following line from /etc/hosts file to eliminate this error: <pre> ::1 localhost ... </pre> ### 2. make test-all stops with "*** Error code 7" after all tests are finished. This is probably a bug in FreeBSD's make command, but it seems to be caused by two spaces at the end of the last command executed when running make test-all: <pre> exec ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./tool/lib/_tmpdir "./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/.excludes --name=!/memory_leak/ ←(*here!!) </pre> To fix this error, modify common.mk line 317 or 965 using attachments(one or the other is sufficient) : <pre> % patch < patch-common.mk-TEST_EXCLUDE.txt (or) % patch < patch-common.mk-yes-test-all.txt </pre> Then re-create the Makefile so that "make test-all" completes successfully. <pre> % ./configure % make test-all BASERUBY = /usr/local/bin/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -shared CFLAGS = -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wundef XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/x86_64-freebsd13.4 -I./include -I. -I./prism -I./enc/unicode/15.0.0 -Dmodular_gc_dir= CPPFLAGS = DLDFLAGS = -Wl,--compress-debug-sections=zlib -Wl,-soname,showflags -fstack-protector-strong -pie SOLIBS = -lexecinfo -lprocstat -lz -lrt -lrt -ldl -lcrypt -lm -lthr LANG = ja_JP.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = no YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/mnt/home/sakamoto/ruby-3.4.1/yjit/target/release/' ./yjit/src/lib.rs FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67) Target: x86_64-unknown-freebsd13.4 Thread model: posix InstalledDir: /usr/bin generating enc.mk generating encdb.h encdb.h unchanged making enc making srcs under enc generating transdb.h transdb.h unchanged making trans making encs generating makefiles ext/configure-ext.mk ext/configure-ext.mk unchanged installing default coverage libraries installing default date_core libraries installing digest libraries installing default digest libraries installing default sha2 libraries installing default fiddle libraries installing default console libraries installing default libraries installing default monitor libraries installing default objspace libraries installing default openssl libraries installing default pathname libraries installing default psych libraries installing default pty libraries installing default ripper libraries installing default libraries installing default socket libraries installing default strscan libraries `ruby' is up to date. Run options: --seed=37281 "--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/.excludes --name=!/memory_leak/ -- # Running tests: Finished tests in 669.890724s, 47.8541 tests/s, 9779.2801 assertions/s. 32057 tests, 6551049 assertions, 0 failures, 0 errors, 191 skips ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-freebsd13.4] % </pre> Now "make check" will pass all tests and return "check succeeded" and exit normally (attachment:"ruby34-make-check.txt"). ---Files-------------------------------- patch-common.mk-TEST_EXCLUDE.txt (433 Bytes) patch-common.mk-yes-test-all.txt (373 Bytes) ruby34-make-check.txt (14.7 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:120745] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by jacobcarlborg (Jacob Carlborg) 20 Jan '25

20 Jan '25

Issue #14582 has been updated by jacobcarlborg (Jacob Carlborg). I'm really interested in using DTrace on Ruby as well. One of the major advantages of DTrace is that it's always available and doesn't require any code changes or restarts of the system that is being instrumented. But with the current way that USDT probes are implemented in Ruby it defeats many of the advantages of DTrace. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-111578 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * 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: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