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

[ruby-core:120579] [Ruby master Feature#21020] Sync sig directory for prism of default gem.
by ksss (Yuki Kurihara) 08 Oct '26

08 Oct '26

Issue #21020 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Feature #21020: Sync sig directory for prism of default gem. https://bugs.ruby-lang.org/issues/21020 * Author: ksss (Yuki Kurihara) * Status: Open ---------------------------------------- Currently, the type signatures (RBS) for the default gem is not available. **Prism** is the only default gem with type signatures, but this number is expected to increase in the future. As a first step to resolving this issue, I propose including the `sig` directory of Prism as a default gem in the synchronization process. PR: https://github.com/ruby/ruby/pull/12541 -- https://bugs.ruby-lang.org/

5 6

[ruby-core:119757] [Ruby master Bug#20872] Undefined RUBY_API_VERSION_* macros used in <ruby/backward/cxxanyargs.hpp>
by hanazuki (Kasumi Hanazuki) 08 Oct '26

08 Oct '26

Issue #20872 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #20872: Undefined RUBY_API_VERSION_* macros used in <ruby/backward/cxxanyargs.hpp> https://bugs.ruby-lang.org/issues/20872 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 3.4.0preview2 (2024-10-07 master 32c733f57b) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I just noticed that C++ compilers warn for undefined RUBY_API_VERSION_MAJOR/RUBY_API_VERSION_MINOR macros in `<ruby/backward/cxxanyargs.hpp>` when preprocessing `<ruby.h>`. ``` % cat test.cpp #include <ruby.h> % clang++ -Wundef -I ~/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0 -I ~/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/x86_64-linux -c test.cpp -o /dev/null In file included from test.cpp:1: In file included from /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby.h:38: In file included from /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/ruby.h:27: In file included from /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/internal/anyargs.h:83: /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/backward/cxxanyargs.hpp:540:6: warning: 'RUBY_API_VERSION_MAJOR' is not defined, evaluates to 0 [-Wundef] #if (RUBY_API_VERSION_MAJOR * 100 + RUBY_API_VERSION_MINOR) >= 301 ^ /home/kasumi/.rbenv/versions/3.4.0-preview2/include/ruby-3.4.0+0/ruby/backward/cxxanyargs.hpp:540:37: warning: 'RUBY_API_VERSION_MINOR' is not defined, evaluates to 0 [-Wundef] #if (RUBY_API_VERSION_MAJOR * 100 + RUBY_API_VERSION_MINOR) >= 301 ^ 2 warnings generated. ``` The offending code was introduced in commit:01825e8bffd. The accompanying code comment says a deprecation warning should be emitted for some use-cases (passing ANYARGS function pointers to `rb_define_method`-series functions) with Ruby 3.x, which looks not working as intended for the current Ruby versions. This seems effectively doing no harm but just disturbing for extension developers. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?
by ivoanjo (Ivo Anjo) 07 Oct '26

07 Oct '26

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

4 4

[ruby-core:114332] [Ruby master Bug#19794] Ruby 3.2.2 fails to build on macOS Sonoma betas
by jhaungs (Jim Haungs) 02 Oct '26

02 Oct '26

Issue #19794 has been reported by jhaungs (Jim Haungs). ---------------------------------------- Bug #19794: Ruby 3.2.2 fails to build on macOS Sonoma betas https://bugs.ruby-lang.org/issues/19794 * Author: jhaungs (Jim Haungs) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- With Big Sur, Apple deprecated putting dylibs in /usr/local/lib. In Sonoma (beta 4), this directory has disappeared completely. However, ruby's configure script depends on its existence. So, virtually every ruby installer (RVM, rbenv, asdf, ruby-build, and even building from source tarball) fails. When building ruby 3.2.2 from source, the configure step outputs the irritatingly useless "something wrong with LDFLAGS" error message and fails to build. The solution was to `cd /usr/local; sudo mkdir lib` to create the missing lib directory under /usr/local. It would be nice to remove this dependency from the configure script. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:111740] [Ruby master Bug#19325] Windows support lacking.
by dsisnero (Dominic Sisneros) 29 Sep '26

29 Sep '26

Issue #19325 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Bug #19325: Windows support lacking. https://bugs.ruby-lang.org/issues/19325 * Author: dsisnero (Dominic Sisneros) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby's support on windows has always been second class. With some of the recent decisions, windows support is falling even more behind. Recent developments in mjit and yjit that exclude windows are two glaring issues that should be corrected. Googling 'percent of windows vs other operating systems' and it shows windows has a share of 76%. Ceding that users to python and other programming languages has to be one of the reasons python continues get more market share from ruby. With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows? Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2. Even Crystal language has a version that runs on windows without needing msys2. -- https://bugs.ruby-lang.org/

11 13

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 14 Sep '26

14 Sep '26

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:117750] [Ruby master Bug#20464] Redundant returns are unreachable in coverage
by kddnewton (Kevin Newton) 14 Sep '26

14 Sep '26

Issue #20464 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20464: Redundant returns are unreachable in coverage https://bugs.ruby-lang.org/issues/20464 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- With the following code: ```ruby def meth_return(a) return if a return end ``` If you run coverage on it, it's not possible for it to hit line 3, because there isn't a line event, because the return node was eliminated from the AST before it was compiled. There is a `putnil` instruction, so it's possible for us to attach a line event for it, but the compiler doesn't today. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:111789] [Ruby master Feature#19333] Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
by ioquatix (Samuel Williams) 14 Sep '26

14 Sep '26

Issue #19333 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks. https://bugs.ruby-lang.org/issues/19333 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 end ``` Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling). In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense. I propose that assigning `nil` to "locals" or "storage" should effectively delete them. e.g. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 Thread.current[name] = nil # delete association end ``` A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC. -- https://bugs.ruby-lang.org/

3 10

[ruby-core:116041] [Ruby master Bug#20155] Using value of rb_fiber_scheduler_current() crashes Ruby
by paddor (Patrik Wenger) 14 Sep '26

14 Sep '26

Issue #20155 has been reported by paddor (Patrik Wenger). ---------------------------------------- Bug #20155: Using value of rb_fiber_scheduler_current() crashes Ruby https://bugs.ruby-lang.org/issues/20155 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While trying to manually block/unblock fibers from an extension using the Fiber Scheduler, I noticed that using the return value of `rb_fiber_scheduler_current()` crashes Ruby. I've created a minimal extension gem called "fiber_blocker". Its test suite shows the behavior. See https://github.com/paddor/fiber_blocker, especially the lines containing `FIXME`. Passing `Fiber.scheduler` to the extension functions works. But letting it get the current scheduler itself does not seem to work. Is `rb_fiber_scheduler_current()` not the equivalent to `Fiber.scheduler`? Even just printing the its return value with `#p` will crash Ruby. Ruby either crashes like this: ``` # Running: T1 BEGIN T2 BEGIN T1 END ..T1 BEGIN ext: blocking fiber passed scheduler = #<Scheduler:0x00007fc5f22d39e8 @readable={}, @writable={}, @waiting={}, @closed=false, @lock=#<Thread::Mutex:0x00007fc5f22ec8d0>, @blocking={}, @ready=[], @urgent=[#<IO:fd 5>, #<IO:fd 6>]> T2 BEGIN ext: unblocking fiber T1 END .E Finished in 1.007014s, 3.9721 runs/s, 2.9791 assertions/s. 1) Error: TestFiberBlocker#test_fiber_blocker_current_fiber: fatal: machine stack overflow in critical region No backtrace ``` Or with a segfault: ``` # Running: FiberBlocker.test works. .T1 BEGIN T2 BEGIN T1 END .T1 BEGIN ext: blocking fiber /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40: [BUG] Segmentation fault at 0x00000000390d8f98 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0012 e:000011 CFUNC :block_fiber c:0002 p:0014 s:0006 e:000005 BLOCK /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block in test_fiber_blocking_in_ext' /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block_fiber' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 4 -- Machine register context ------------------------------------------------ RIP: 0x00007f1554f17ad8 RBP: 0x00000000390d8f90 RSP: 0x00007f153a79e280 RAX: 0x00007f1554addba8 RBX: 0x00007f153a79eab0 RCX: 0x0000000000000000 RDX: 0x00007f1554ade600 RDI: 0x00007f15551e8788 RSI: 0x0000000000000ae1 R8: 0x000000000000002b R9: 0x00007f153a79f038 R10: 0x00007f1554c0b9b0 R11: 0x00007f153a79e490 R12: 0x0000000000000ae1 R13: 0x0000000000000000 R14: 0x0000000000000000 R15: 0x000055ab732d7df0 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_print_backtrace+0x14) [0x7f1554f24961] /home/user/src/ruby-3.3.0/vm_dump.c:820 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_bugreport) /home/user/src/ruby-3.3.0/vm_dump.c:1151 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_bug_for_fatal_signal+0x104) [0x7f1554d1c214] /home/user/src/ruby-3.3.0/error.c:1065 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(sigsegv+0x4f) [0x7f1554e700df] /home/user/src/ruby-3.3.0/signal.c:926 /lib/x86_64-linux-gnu/libc.so.6(0x7f1554842520) [0x7f1554842520] /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_CLASS+0x0) [0x7f1554f17ad8] ./include/ruby/internal/globals.h:178 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(gccct_method_search) /home/user/src/ruby-3.3.0/vm_eval.c:475 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv_scope) /home/user/src/ruby-3.3.0/vm_eval.c:1063 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv) /home/user/src/ruby-3.3.0/vm_eval.c:1084 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_inspect+0x19) [0x7f1554dc1569] /home/user/src/ruby-3.3.0/object.c:697 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby__sfvextra+0x11a) [0x7f1554e7223a] /home/user/src/ruby-3.3.0/sprintf.c:1119 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(BSD_vfprintf+0xa69) [0x7f1554e73059] /home/user/src/ruby-3.3.0/vsnprintf.c:830 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_SET_CLASS_RAW+0x0) [0x7f1554e75b56] /home/user/src/ruby-3.3.0/sprintf.c:1168 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby_vsprintf0) /home/user/src/ruby-3.3.0/sprintf.c:1169 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_enc_vsprintf+0x5d) [0x7f1554e75ecd] /home/user/src/ruby-3.3.0/sprintf.c:1195 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_sprintf+0x9d) [0x7f1554e7607d] /home/user/src/ruby-3.3.0/sprintf.c:1225 /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/lib/fiber_blocker/fiber_blocker.so(block_fiber+0x4a) [0x7f1554ad430a] ../../../../ext/fiber_blocker/fiber_blocker.c:29 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_cfp_consistent_p+0x0) [0x7f1554ef64b4] /home/user/src/ruby-3.3.0/vm_insnhelper.c:3490 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame_) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3492 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3518 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_other) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3544 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_sendish+0x9e) [0x7f1554f06f87] /home/user/src/ruby-3.3.0/vm_insnhelper.c:5581 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_exec_core) /home/user/src/ruby-3.3.0/insns.def:834 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_exec+0x19a) [0x7f1554f0d1fa] /home/user/src/ruby-3.3.0/vm.c:2486 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_invoke_proc+0x5f) [0x7f1554f12e0f] /home/user/src/ruby-3.3.0/vm.c:1728 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_fiber_start+0x1ba) [0x7f1554cf098a] /home/user/src/ruby-3.3.0/cont.c:2536 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(fiber_entry+0x20) [0x7f1554cf0d00] /home/user/src/ruby-3.3.0/cont.c:847 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_threadptr_root_fiber_setup) (null):0 ``` I hope I'm not missing something obvious. My C isn't very good. -- https://bugs.ruby-lang.org/

2 12

[ruby-core:111960] [Ruby master Bug#19364] Issue with tracepoint enable/disable across ractors
by luke-gru (Luke Gruber) 09 Sep '26

09 Sep '26

Issue #19364 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19364: Issue with tracepoint enable/disable across ractors https://bugs.ruby-lang.org/issues/19364 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This sometimes segfaults: ```ruby def test_enable_disable_in_multiple_ractors_with_target rs = [] 100.times do |i| # setup new iseqs Kernel.define_method :"my_method_to_change_for_tracing_#{i}" do true end end 100.times do |i| rs << Ractor.new(i) do |j| meth = :"my_method_to_change_for_tracing_#{j}" tp = TracePoint.new(:line) { } # local to ractor 100.times do tp.enable(target: method(meth)) # change iseq internals of given method, should be done with lock tp.disable # disable hooks should hold lock too, changes method definition internals end end end rs.each(&:take) # shouldn't raise end test_enable_disable_in_multiple_ractors_with_target() ``` Changing iseq internals is done without the VM lock. This is true in Tracepoint#enable and Tracepoint#disable methods. I have a patch coming. -- https://bugs.ruby-lang.org/

3 2