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

[ruby-core:121222] [Ruby master Bug#21167] Visual Studio 2022 17.13.x couldn't build ruby.exe
by hsbt (Hiroshi SHIBATA) 23 May '25

23 May '25

Issue #21167 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21167: Visual Studio 2022 17.13.x couldn't build ruby.exe https://bugs.ruby-lang.org/issues/21167 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `miniruby.exe` built by Visual Studio 2022 17.13.0-2 is not working with our build process. ``` user32.lib advapi32.lib shell32.lib ws2_32.lib iphlpapi.lib gmp.lib imagehlp.lib shlwapi.lib bcrypt.lib linking miniruby.exe Creating library miniruby.lib and object miniruby.exp [BUG] heap_idx_for_size: allocation size too large (size=56u, heap_idx=891288545u) ruby 3.5.0dev (2025-03-03T02:17:14Z master a47e686cb6) [x64-mswin64_140] -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 0 Ruby thread count for this ractor: 0 -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(ZwWaitForSingleObject+0x14) [0x00007FF9057BF854] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF902CFCE1F] C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_print_backtrace+0x3e) [0x00007FF63DC37E7E] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm_dump.c:859 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_vm_bugreport+0x1ba) [0x00007FF63DC3803E] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm_dump.c:1170 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_bug_without_die_internal+0x72) [0x00007FF63DB0255A] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\error.c:1097 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_bug+0x20) [0x00007FF63DB02448] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\error.c:1117 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(newobj_of+0x1e7) [0x00007FF63DB186FB] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\gc.c:1007 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(typed_data_alloc+0xc3) [0x00007FF63DB212CF] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\gc.c:1084 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(rb_data_typed_object_zalloc+0x3b) [0x00007FF63DB19797] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\gc.c:1107 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(pin_array_list_new+0x25) [0x00007FF63DC1B5D9] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm.c:4387 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(Init_vm_objects+0x17) [0x00007FF63DC1665B] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\vm.c:4446 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(ruby_setup+0x3f) [0x00007FF63DB08C1B] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\eval.c:83 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(ruby_init+0x9) [0x00007FF63DB089AD] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\eval.c:98 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(wmain+0x3a) [0x00007FF63DA8103A] C:\Users\hsbt\DevDrive\github.com\ruby\ruby\main.c:51 C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\miniruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF63DC9DE88] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x17) [0x00007FF90409E8D7] -- Other runtime information ----------------------------------------------- NMAKE : fatal error U1077: '@ miniruby.exe -v' : return code '0x3' Stop. ``` I disabled that version on our CI temporary. * https://github.com/ruby/ruby/pull/12830 * https://github.com/ruby/actions/pull/81 -- https://bugs.ruby-lang.org/

2 7

[ruby-core:122241] [Ruby Bug#21364] Constant lookup in namespaces should be consistent
by tenderlovemaking (Aaron Patterson) 22 May '25

22 May '25

Issue #21364 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21364: Constant lookup in namespaces should be consistent https://bugs.ruby-lang.org/issues/21364 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-22T23:07:21Z rm-assertion 17e71c7a24) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This might be related to #21363, but I'm not sure. I expect that a top level `Bar` constant should have the same value as `Object::Bar`. For example: ```ruby File.binwrite("ns.rb", <<-RUBY) # namespace 3 Bar = 123 module M def self.test p Bar: Bar p "Object::Bar": Object::Bar end TEST = -> { p Bar: Bar p "Object::Bar": Object::Bar } end RUBY Bar = 456 ns = Namespace.new ns.load "./ns.rb" ns::M.test ns::M::TEST.call ``` The output is this: ``` RUBY_NAMESPACE=1 ./miniruby test.rb ./miniruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. {Bar: 123} {"Object::Bar": 123} {Bar: 123} {"Object::Bar": 456} ``` But I expected this: ``` {Bar: 123} {"Object::Bar": 123} {Bar: 123} {"Object::Bar": 123} ``` Constant lookups in methods seem to behave differently than in lambdas. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122203] [Ruby Feature#21353] Add shape_id to RBasic under 32 bit
by byroot (Jean Boussier) 22 May '25

22 May '25

Issue #21353 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21353: Add shape_id to RBasic under 32 bit https://bugs.ruby-lang.org/issues/21353 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Currently on 64bit systems, for every types, the `shape_id` is stored inside the `RBasic.flags` field, and is 32bit long. However, on 32bit systems like i686 and WASM, it is much more complicated. For `T_OBJECT`, `T_CLASS` and `T_MODULE`, the `shape_id` is stored as part of "user flags" in `FL_USER4-19`, and for all other types it's stored alongside the instance variable in the `generic_fields_tbl`, which means a hash lookup is required to access it. This situation makes a lot of routine noticeably more complicated, with numerous codepath taken only by 32bit systems, because to avoid doing two hash-lookup per ivar access, the code need a lot of contortions. You can look for `SHAPE_IN_BASIC_FLAGS` to have an idea of the added complexity. In addition, it forces us to duplicate some bits of information. For instance `RUBY_FL_FREEZE` is redundant with the `shape_id`. The shape already record that the object is frozen, and the only reason `RUBY_FL_FREEZE` hasn't been eliminated is because on 32bits the `shape_id` isn't store inline for some objects. Similarly, `RUBY_FL_EXIVAR` is redundant with the `shape_id`, because to know whether an object has ivars, you can simply check if `shape_id == 0`. Reclaiming these bits would be very useful for Ractors, as we'd need two bits in objects to be able to implement [lightwieght locks](https://webkit.org/blog/6161/locking-in-webkit/). Yet another complication, is that on 32bit systems, the `shape_id` is only 16bits long. I have the project to use the upper bits of the `shape_id` to store metadata, such as the `frozen` and `too_complex` status, allowing to test for this without chasing a pointer: https://github.com/ruby/ruby/pull/13289. But this currently can't be done on 32bit sytems, both because accessing the `shape_id` might require a hash-lookup, and also because it's only 16bits long, so every single bit used for tagging severely restrict the maximum number of shapes. ### Proposal To simplify all this, we propose that on 32bit systems, we add a `VALUE shape_id` in `RBasic`: ```c struct RBasic { VALUE flags; const VALUE klass; #if RBASIC_SHAPE_ID_FIELD VALUE shape_id; #endif } ``` This ensure that on 32bits, all objects have their `shape_id` always at the same predictable offset, and 32bits long. As you can see on the pull request, it simplify the code quite significantly: https://github.com/ruby/ruby/pull/13341, and there's more cleanup that can be done. The downside obviously is that on 32bit, objects would grow from `20B` to `24B`. ### Pull Request You can find the proposed patch at: https://github.com/ruby/ruby/pull/13341 cc @tenderlovemaking and @jhawthorn Also FYI @katei because as the maintainer of WASM I assume this impact you the most. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122175] [Ruby Misc#21348] Should Tracepoint track retry as another "call" event?
by karthikc (Karthik Chandrasekariah) 22 May '25

22 May '25

Issue #21348 has been reported by karthikc (Karthik Chandrasekariah). ---------------------------------------- Misc #21348: Should Tracepoint track retry as another "call" event? https://bugs.ruby-lang.org/issues/21348 * Author: karthikc (Karthik Chandrasekariah) * Status: Open ---------------------------------------- When `retry` is executed in a method, Tracepoint records it as a new "call" event. ``` ruby # tracepoint-retry.rb # method that retries once def foo attempts ||= 1 raise "Fail" if attempts == 1 rescue attempts += 1 retry end trace = TracePoint.new(:call, :return) do |tp| p [tp.event, tp.method_id] end trace.enable foo ``` ``` shell $ ruby -v ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-darwin24] $ ruby tracepoint-retry.rb [:call, :foo] [:call, :foo] [:return, :foo] ``` It results in multiple "call" events and a single "return" event. Since the `retry` doesn't technically leave and re-enter the method, should we change Tracepoint to not fire the second "call" event? Context - I am building a library that tracks everything that happened in a block of code. This behavior makes it look like `foo` was called within `foo` but the outer call never returned/completed. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122191] [Ruby Bug#21351] Ruby master segfaults when initializing `Zlib::GzipReader`
by st0012 (Stan Lo) 19 May '25

19 May '25

Issue #21351 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21351: Ruby master segfaults when initializing `Zlib::GzipReader` https://bugs.ruby-lang.org/issues/21351 * Author: st0012 (Stan Lo) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-13T14:16:58Z master bb180b87b4) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ### Ruby Version ``` ruby 3.5.0dev (2025-05-13T14:16:58Z master bb180b87b4) +PRISM [arm64-darwin24] last_commit=[Bug #21331] Prohibit modification during stlike loop ``` ### Steps to reproduce ``` $ ruby -e "require 'zlib'; Zlib::GzipReader.new('')" ``` ### C backtrace ``` /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_vm_bugreport+0xb6c) [0x102571c30] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1023a3ebc] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(sigsegv+0x84) [0x1024caae0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x1998fb624] /Users/hung-wulo/.gem/ruby/ruby-master/gems/zlib-3.2.1/lib/zlib.bundle(gzfile_new+0x30) [0x11d6d2efc] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_class_alloc+0xac) [0x1024366e8] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(vm_exec_core+0x38f4) [0x102549ac4] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_vm_exec+0x1b0) [0x102544e08] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(rb_ec_exec_node+0x8c) [0x1023aef64] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(ruby_run_node+0x40) [0x1023aee8c] /Users/hung-wulo/.rubies/ruby-master/bin/ruby(main+0x68) [0x1022f0980] ``` Full report is in the attached file ---Files-------------------------------- crash_report.txt (20.2 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121830] [Ruby Feature#21309] Can Thread::Mutex be Ractor shareable?
by osyoyu (Daisuke Aritomo) 19 May '25

19 May '25

Issue #21309 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21309: Can Thread::Mutex be Ractor shareable? https://bugs.ruby-lang.org/issues/21309 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- ## Background Keeping a `Mutex` object in a constant or a class instance variable is a common pattern seen in code with thread safety in mind. However, this kind of code does not play well with Ractors: ```ruby require 'thread' class C MUTEX = Mutex.new def self.foo MUTEX.synchronize { p 1 } end end Ractor.new { C.foo }.take ``` ``` t.rb:11: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x000000011d80f368 run> terminated with exception (report_on_exception is true): t.rb:7:in 'C.foo': can not access non-shareable objects in constant C::MUTEX by non-main ractor. (Ractor::IsolationError) from t.rb:12:in 'block in <main>' <internal:ractor>:711:in 'Ractor#take': thrown by remote Ractor. (Ractor::RemoteError) from t.rb:13:in '<main>' t.rb:7:in 'C.foo': can not access non-shareable objects in constant C::MUTEX by non-main ractor. (Ractor::IsolationError) from t.rb:12:in 'block in <main>' ``` Many libraries follow this pattern. `Mutex` not being Ractor shareable is blocking these libraries from being used from inside Ractors. `Timeout` in stdlib in particular has large impact since it is required from many other gems by default, including `net/http`. https://github.com/ruby/timeout/blob/v0.4.3/lib/timeout.rb#L49-L50 https://github.com/lostisland/faraday/blob/v2.13.1/lib/faraday/middleware.r… ## Proposal Make built-in concurrency primitives (Thread::Mutex, Thread::ConditionVariable and Thread::Queue) Ractor shareable. While this idea may not be strictly aligned with idea of the Ractor world (exchanging messages for controlling concurrency?), I have the feeling that too many code is blocked from running in Ractors because `Mutex` is not Ractor shareable. Allowing `Mutex`es to be shared would make a large portion of existing Ruby code Ractor-compatible, or at least make migration much easier. I believe that it won't be semantically incorrect, since they are concurrency primitives after all. One thing to consider that the current `Mutex` implementation is based on the GVL (I believe so). Migration to some other implementation e.g. pthread_mutex or CRITICAL_SECTION may be needed to make Mutex work well on Ractors. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:122192] [Ruby Bug#21352] Invalid read in shape lookup code
by Earlopain (Earlopain _) 19 May '25

19 May '25

Issue #21352 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21352: Invalid read in shape lookup code https://bugs.ruby-lang.org/issues/21352 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-19T04:27:50Z master 40c957ba21) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism runs tests with valgrind and it recently started to report an invalid read in `rb_shape_lookup`. Example workflow: https://github.com/ruby/prism/actions/runs/15111527208/job/42471945845?pr=3… ``` Invalid read of size 8 rb_shape_lookup (shape.c:347) rb_obj_shape (shape.h:184) rb_shape_obj_too_complex_p (shape.c:1098) rb_free_generic_ivar (variable.c:1274) rb_gc_obj_free_vm_weak_references (gc.c:2061) rb_gc_impl_shutdown_free_objects (default.c:2965) rb_objspace_free_objects (gc.c:1759) ruby_vm_destruct (vm.c:3209) rb_ec_cleanup (eval.c:263) ruby_run_node (eval.c:319) rb_main (main.c:42) main (main.c:62) ``` cc @byroot since you did recent changes around the shape code. I'm lacking knowledge to dig into this, so it may be a false positive (it uses https://github.com/Shopify/ruby_memcheck which does some heuristics). I confirmed that this happens locally on current ruby-dev when running `bundle exec rake test:valgrind` from `ruby/prism`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122149] [Ruby Bug#21345] crash on evaluating 'a=>a,*,'
by masterleep2 (Bill Lipa) 19 May '25

19 May '25

Issue #21345 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #21345: crash on evaluating 'a=>a,*,' https://bugs.ruby-lang.org/issues/21345 * Author: masterleep2 (Bill Lipa) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` ruby -e 'a=>a,*,' -e: [BUG] Unexpected node type in pattern matching expression: PM_IMPLICIT_REST_NODE ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [arm64-darwin24] -- 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:0001 p:0000 s:0003 E:0001f0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /opt/local/lib/libruby.3.4.dylib(rb_vm_bugreport+0xb6c) [0x104cbcfdc] /opt/local/lib/libruby.3.4.dylib(rb_bug_without_die_internal+0xfc) [0x104afa12c] /opt/local/lib/libruby.3.4.dylib(rb_bug+0x1c) [0x104e07970] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern.cold.2+0x0) [0x104e0750c] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern+0x42a8) [0x104abd78c] /opt/local/lib/libruby.3.4.dylib(pm_compile_pattern+0x3f90) [0x104abd474] /opt/local/lib/libruby.3.4.dylib(pm_compile_match_required_node+0x3b4) [0x104abdb54] /opt/local/lib/libruby.3.4.dylib(pm_compile_node+0x1670) [0x104a8659c] /opt/local/lib/libruby.3.4.dylib(pm_compile_scope_node+0x1c34) [0x104ac2018] /opt/local/lib/libruby.3.4.dylib(pm_iseq_compile_node+0x84) [0x104a84e60] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_with_opt_try+0x1c) [0x104b5cbc8] /opt/local/lib/libruby.3.4.dylib(rb_protect+0xbc) [0x104b060cc] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_with_opt+0x14c) [0x104b5c034] /opt/local/lib/libruby.3.4.dylib(pm_iseq_new_main+0xc4) [0x104b5c23c] /opt/local/lib/libruby.3.4.dylib(ruby_process_options+0x16a4) [0x104c12a30] /opt/local/lib/libruby.3.4.dylib(ruby_options+0xb0) [0x104b04b04] /opt/local/bin/ruby3.4(main+0x64) [0x1041eff20] ``` ---Files-------------------------------- crash.txt (14.1 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115995] [Ruby master Bug#20112] Ractors not working properly in ruby 3.3.0
by ariasdiniz (Aria Diniz) 19 May '25

19 May '25

Issue #20112 has been reported by ariasdiniz (Aria Diniz). ---------------------------------------- Bug #20112: Ractors not working properly in ruby 3.3.0 https://bugs.ruby-lang.org/issues/20112 * Author: ariasdiniz (Aria Diniz) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I recently installed Ruby 3.3.0, and noticed that some of my scripts that use Ractors started to struggle with performance. After doing some benchmarks, I noticed that, while Ractors seem to be working well on Ruby 3.2.2, they're not working properly on 3.3.0. I'm using Ubuntu 22.04.3 LTS Here is the benchmark code: ``` ruby # frozen_string_literal: true require 'benchmark' Ractor.new { :warmup } if defined?(Ractor) Benchmark.bmbm do |x| x.report("Thread: ") do threads = [] 8.times do |i| threads << Thread.new do 20000000.times do |j| ((i * 20000000) + j)**2 end end end threads.each(&:join) end x.report("Ractor: ") do ractors = [] 0..8.times do |i| ractors << Ractor.new(i) do |k| 20000000.times do |j| ((k * 20000000) + j)**2 end end end ractors.map(&:take) end end ``` Here is the results for Ruby 3.2.2: Rehearsal -------------------------------------------- Thread: 7.666909 0.001091 7.668000 ( 7.675266) Ractor: 19.318528 0.012017 19.330545 ( 2.505888) ---------------------------------- total: 26.998545sec user system total real Thread: 7.918141 0.004011 7.922152 ( 7.928772) Ractor: 19.366414 0.003954 19.370368 ( 2.517993) Here is the results for Ruby 3.3.0: Rehearsal -------------------------------------------- Thread: 8.634152 0.010895 8.645047 ( 8.645104) Ractor: 100.172179 0.035985 100.208164 ( 15.213245) --------------------------------- total: 108.853211sec user system total real Thread: 9.451236 0.004002 9.455238 ( 9.460132) Ractor: 118.463294 0.119942 118.583236 ( 18.462157) -- https://bugs.ruby-lang.org/

5 4

[ruby-core:122091] [Ruby Bug#21338] TracePoint Not Triggered for Kernel#block_given?
by cfis (Charlie Savage) 19 May '25

19 May '25

Issue #21338 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21338: TracePoint Not Triggered for Kernel#block_given? https://bugs.ruby-lang.org/issues/21338 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When updating ruby-prof for Ruby 3.4, various tests now fail because a method enter/leave tracepoint is not triggered for `Kernel#block_given?` For example: https://github.com/ruby-prof/ruby-prof/blob/master/test/line_number_test.rb… In 3.3 a tracepoint was triggered but not in earlier Ruby versions. -- https://bugs.ruby-lang.org/

3 5