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

[ruby-core:125252] [Ruby Bug#21996] Crash when modifying instance variables during inspect or Marshal dump
by jhawthorn (John Hawthorn) 26 Jun '26

26 Jun '26

Issue #21996 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21996: Crash when modifying instance variables during inspect or Marshal dump https://bugs.ruby-lang.org/issues/21996 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In #15968 describes an issue where instance variables being modified lead to incorrect Marshal output being generated, which was partially solved by checking for the number of IVs changing and raising an exception. However, if enough IVs removed this could cause the buffer to be moved/re-embedded, but we'd still attempt to read the now removed variables. I've found this reproduces back to Ruby 3.3, but suspect there are other ways to hit issues on older versions. We've seen the test from #15968 start failing on CI recently (likely because the changes to size pools makes this crash reproducible) https://github.com/ruby/ruby/actions/runs/24247666394/job/70803324392 ``` ruby class Evil def initialize(parent) @parent = parent end def marshal_dump @parent.instance_variables.each { |v| @parent.remove_instance_variable(v) } {} end def marshal_load(data) = nil end obj = Object.new obj.instance_variable_set(:@evil, Evil.new(obj)) 10.times { |i| obj.instance_variable_set(:"@v#{i}", 0) } Marshal.dump(obj) # SEGV ``` ``` ruby class Evil def initialize(parent) @parent = parent end def inspect @parent.instance_variables.each { |v| @parent.remove_instance_variable(v) } "" end end obj = Object.new obj.instance_variable_set(:@evil, Evil.new(obj)) 10.times { |i| obj.instance_variable_set(:"@v#{i}", 0) } obj.inspect # SEGV ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116949] [Ruby master Misc#20303] Troubleshooting Guide for Common Issues with GMC Acadia
by adamrojas (Adam Rojas) 23 Jun '26

23 Jun '26

Issue #20303 has been reported by adamrojas (Adam Rojas). ---------------------------------------- Misc #20303: Troubleshooting Guide for Common Issues with GMC Acadia https://bugs.ruby-lang.org/issues/20303 * Author: adamrojas (Adam Rojas) * Status: Open ---------------------------------------- Owning a GMC Acadia brings numerous benefits, yet like any vehicle, it may encounter issues. In this guide, we’ll delve into common problems reported by GMC Acadia owners and offer effective solutions. ![Troubleshooting Guide for Common Issues with GMC Acadia](https://autorepairandservice.files.wordpress.com/2024/02/troublesho… Whether you’re dealing with transmission faults, engine light codes, or other issues, we’ve got you covered. ## **Troubles with Transmission and Check Engine Light:** ![Troubles with Transmission and Check Engine Light](https://autorepairandservice.files.wordpress.com/2024/02/troubles-wi… One significant challenge faced by GMC Acadia owners revolves around transmission faults, often accompanied by the illumination of the check engine light. This issue, reported by numerous individuals, demands prompt attention to prevent further complications. Seeking assistance from experienced professionals is recommended to diagnose and address these transmission-related concerns effectively, ensuring the continued reliability and performance of your vehicle. ## **Interpreting Check Engine Light Codes:** ![Interpreting Check Engine Light Codes](https://autorepairandservice.files.wordpress.com/2024/02/interpretin… Another common issue encountered by GMC Acadia owners involves the activation of the check engine light, often accompanied by specific diagnostic trouble codes (DTCs). Understanding these codes is essential for identifying underlying issues promptly. Seeking assistance from a qualified mechanic for thorough diagnostics and appropriate remedies is advised to prevent potential engine damage and ensure continued vehicle reliability. ## **Addressing Gas Cap Concerns and Check Engine Light Illumination:** ![Addressing Gas Cap Concerns and Check Engine Light Illumination](https://autorepairandservice.files.wordpress.com/2024/02/addr… Another area of concern for GMC Acadia owners involves issues related to the gas cap, which can lead to the illumination of the check engine light. This problem, while less common, should not be overlooked. It’s important to ensure the gas cap is securely tightened to prevent evaporation and maintain proper fuel system pressure. If the check engine light persists after verifying the gas cap’s tightness, seeking assistance from a qualified technician is advisable to diagnose and resolve any underlying issues effectively. ## **Navigating GMC Acadia Electrical Issues:** ![Navigating GMC Acadia Electrical Issues](https://autorepairandservice.files.wordpress.com/2024/02/navigating… Electrical problems can pose significant challenges for GMC Acadia owners, affecting various systems within the vehicle. These issues might manifest as malfunctioning lights, power window failures, intermittent electrical failures, or battery drainage concerns. Addressing electrical problems promptly is crucial to prevent further complications and ensure the safety and functionality of your Acadia. Seeking assistance from experienced technicians equipped with diagnostic tools and expertise in automotive electrical systems is essential for accurately identifying and resolving these issues, restoring your vehicle’s performance and reliability. ## **Essential Maintenance Tasks for GMC Acadia Owners:** ![Essential Maintenance Tasks for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/essential-… Beyond adhering to scheduled maintenance, there are fundamental tasks that every GMC Acadia owner should prioritize. These include: **1. Regular Brake Fluid Flushes:** To uphold braking effectiveness, it’s crucial to schedule regular brake fluid flushes. This process helps prevent contaminants from compromising the brake system’s performance, ensuring optimal safety on the road. **2. Transmission Inspections:** Regular inspections of the transmission are essential for early detection of potential issues. By identifying any signs of wear or malfunction early on, owners can mitigate the risk of costly repairs and ensure smooth operation of their Acadia. **3. Coolant Inspections:** Preventing overheating is vital for maintaining engine health. Regular coolant inspections help owners monitor coolant levels and quality, ensuring proper engine temperature regulation and preventing potential damage due to overheating. **4. Spark Plug Replacements:** Spark plugs play a critical role in engine performance by igniting the air-fuel mixture in the cylinders. Replacing worn-out spark plugs at recommended intervals helps maintain fuel efficiency, prevent misfires, and ensure optimal engine performance. ## **Expert Tips for GMC Acadia Owners:** ![Expert Tips for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/expert-tip… Routine inspections and preventive measures are key to maintaining your GMC Acadia’s performance and longevity. Beyond addressing specific issues and adhering to maintenance schedules, here are some expert tips to keep your vehicle running smoothly: **1. Driving Habits Matter:** Be mindful of your driving habits to minimize wear and tear on your Acadia. Avoid sudden acceleration or braking whenever possible, and practice smooth, gradual maneuvers to reduce strain on the engine, transmission, and other vital components. **2. Stay Informed and Educated:** Stay updated on recalls, service bulletins, and manufacturer recommendations for your GMC Acadia. Joining online forums or communities dedicated to GMC owners can provide valuable insights and tips from fellow enthusiasts and experts. Keeping yourself informed empowers you to make informed decisions about your vehicle’s care and maintenance. By incorporating these expert tips into your maintenance routine, you can ensure that your GMC Acadia remains reliable, efficient, and enjoyable to drive for miles to come. ## **Conclusion:** Being aware of common GMC Acadia issues and following proper maintenance practices can ensure trouble-free ownership. Promptly addressing problems through professional diagnosis and repair, along with adhering to recommended maintenance intervals, can help maintain a reliable and enjoyable driving experience. Thank you for reading this post. If you're looking for a car specialist to opt for a [cheap plastic bumper repair in Manchester](https://servicemycar.com/uk/services/car-bumper-repair-manchest…. So, you can connect with Service My Car and get the best car dent service at a very reasonable price. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125141] [Ruby Bug#21967] `vm_call_cfunc: cfp consistency error` while requiring `nkf.so`
by byroot (Jean Boussier) 23 Jun '26

23 Jun '26

Issue #21967 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21967: `vm_call_cfunc: cfp consistency error` while requiring `nkf.so` https://bugs.ruby-lang.org/issues/21967 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm unfortunately unable to reproduce this consistently. It does happen a few times a day on our production servers, and I have a few core dumps around for investigation if needed. The crash is always while loading `nknf.so`. I'm unfortunately not familiar enough with `cfp` to investigate this much further myself. ``` <PATH>/vendor/bundle/ruby/4.0.0/gems/nkf-0.2.0/lib/nkf.so: [BUG] vm_call_cfunc: cfp consistency error (0x0000ffff80779830, 0x0000ffff807797f8) ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [aarch64-linux] -- Control frame information ----------------------------------------------- c:0032 p:---- s:0172 e:000171 l:y b:0001 TOP [FINISH] c:0031 p:---- s:0169 e:000168 l:y b:---- CFUNC :require c:0030 p:0033 s:0164 e:000163 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0029 p:0145 s:0158 e:000157 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0028 p:0026 s:0149 e:000148 l:y b:0001 TOP <PATH>/vendor/bundle/ruby/4.0.0/gems/nkf-0 [FINISH] c:0027 p:---- s:0146 e:000145 l:y b:---- CFUNC :require c:0026 p:0033 s:0141 e:000140 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0025 p:0145 s:0135 e:000134 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0024 p:0011 s:0126 e:000125 l:y b:0001 TOP <PATH>/vendor/bundle/ruby/4.0.0/gems/mecha [FINISH] c:0023 p:---- s:0123 e:000122 l:y b:---- CFUNC :require c:0022 p:0033 s:0118 e:000117 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0021 p:0145 s:0112 e:000111 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0020 p:0265 s:0103 e:000102 l:y b:0001 TOP <PATH>/vendor/bundle/ruby/4.0.0/gems/mecha [FINISH] c:0019 p:---- s:0100 e:000099 l:y b:---- CFUNC :require c:0018 p:0011 s:0095 e:000094 l:y b:0001 METHOD <internal:<PATH>/vendor/ruby-4.0.2/lib/rub c:0017 p:0033 s:0089 e:000088 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0016 p:0024 s:0083 e:000082 l:n b:---- BLOCK <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl [FINISH] c:0015 p:---- s:0077 e:000076 l:y b:---- CFUNC :each c:0014 p:0027 s:0073 e:000072 l:n b:---- BLOCK <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl [FINISH] c:0013 p:---- s:0069 e:000068 l:y b:---- CFUNC :each c:0012 p:0042 s:0065 e:000064 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl c:0011 p:0013 s:0059 e:000058 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl c:0010 p:0117 s:0054 e:000053 l:y b:0001 TOP <PATH>/config/application.rb:25 [FINISH] c:0009 p:---- s:0051 e:000050 l:y b:---- CFUNC :require_relative c:0008 p:0005 s:0046 e:000045 l:y b:0001 TOP <PATH>/config/environment.rb:2 [FINISH] c:0007 p:---- s:0043 e:000042 l:y b:---- CFUNC :require c:0006 p:0033 s:0038 e:000037 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0005 p:0145 s:0032 e:000031 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0004 p:0011 s:0023 e:000022 l:y b:0001 TOP <PATH>/gems/intercom-sqs/exe/intercom-sqs: [FINISH] c:0003 p:---- s:0011 e:000010 l:y b:---- CFUNC :load c:0002 p:0017 s:0006 e:000005 l:n b:---- EVAL bin/intercom-sqs:6 [FINISH] c:0001 p:0000 s:0003 E:001b40 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bin/intercom-sqs:6:in '<main>' bin/intercom-sqs:6:in 'load' <PATH>/gems/intercom-sqs/exe/intercom-sqs:6:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' <PATH>/config/environment.rb:2:in '<main>' <PATH>/config/environment.rb:2:in 'require_relative' <PATH>/config/application.rb:25:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler.rb:213:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:52:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:52:in 'each' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:58:in 'block in require' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:58:in 'each' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:63:in 'block (2 levels) in require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <internal:<PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/rubygems/core_ext/kernel_require.rb>:37:in 'require' <internal:<PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/rubygems/core_ext/kernel_require.rb>:37:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/mechanize-2.10.0/lib/mechanize.rb:1387:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/mechanize-2.10.0/lib/mechanize/util.rb:3:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/nkf-0.2.0/lib/nkf.rb:5:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_print_backtrace+0x8) [0xaaaab1d0964c] /ruby-4.0.2/vm_dump.c:1105 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_bugreport) /ruby-4.0.2/vm_dump.c:1450 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_bug_without_die_internal+0x70) [0xaaaab1821640] /ruby-4.0.2/error.c:1098 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_bug) /ruby-4.0.2/error.c:1116 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_check_ints+0x0) [0xaaaab19edc54] /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_check_ints) /ruby-4.0.2/vm_core.h:2256 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_pop_frame) /ruby-4.0.2/vm_insnhelper.c:452 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_pop_frame) /ruby-4.0.2/vm_insnhelper.c:461 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3906 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_alias+0x8c) [0xaaaab19fe90c] /ruby-4.0.2/vm_insnhelper.c:4297 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec+0x188) [0xaaaab19fc3f0] /ruby-4.0.2/vm.c:2798 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_yield+0xd0) [0xaaaab1a0131c] /ruby-4.0.2/vm.c:1871 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_TEST_RAW+0x0) [0xaaaab1bf8968] /ruby-4.0.2/array.c:2754 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:514 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:259 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_ary_each) /ruby-4.0.2/array.c:2753 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0x108) [0xaaaab1a0b9f8] /ruby-4.0.2/insns.def:856 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_yield+0xd0) [0xaaaab1a0131c] /ruby-4.0.2/vm.c:1871 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_TEST_RAW+0x0) [0xaaaab1bf8968] /ruby-4.0.2/array.c:2754 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:514 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:259 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_ary_each) /ruby-4.0.2/array.c:2753 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0x108) [0xaaaab1a0b9f8] /ruby-4.0.2/insns.def:856 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x58) [0xaaaab18a1e20] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec+0x188) [0xaaaab19fc3f0] /ruby-4.0.2/vm.c:2798 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(raise_load_if_failed+0x0) [0xaaaab18a108c] /ruby-4.0.2/load.c:851 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_load_internal) /ruby-4.0.2/load.c:853 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_load+0x84) [0xaaaab18a112c] /ruby-4.0.2/load.c:893 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec+0x188) [0xaaaab19fc3f0] /ruby-4.0.2/vm.c:2798 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_ec_exec_node+0x8c) [0xaaaab1824c4c] /ruby-4.0.2/eval.c:283 <PATH>/vendor/ruby-4.0.2/bin/ruby(ruby_run_node+0x3c) [0xaaaab182716c] /ruby-4.0.2/eval.c:321 <PATH>/vendor/ruby-4.0.2/bin/ruby(main+0x70) [0xaaaab1821b30] ./main.c:42 ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:125475] [Ruby Feature#22067] New TypedData bit to allow the type to be freed in parallel
by luke-gru (Luke Gruber) 17 Jun '26

17 Jun '26

Issue #22067 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22067: New TypedData bit to allow the type to be freed in parallel https://bugs.ruby-lang.org/issues/22067 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- CRuby `TypedData` types are used internally in the VM and in C extensions and currently any `free` functions for these types are run with the VM lock held as well as the VM barrier (or, in the case of MMTk, are not freed in parallel). In short, no other Ruby threads or GC threads can run while these `free` functions are called. In order to allow one or more worker GC threads to free these `TypedData` objects, we need a way to specify that a `TypedData` type can be freed in parallel alongside the Ruby GC thread or Ruby code that is being run by another thread. Otherwise, we cannot free these types in the workers and must rely on the Ruby GC thread to do so. This is because it can be unsafe to call these `free` functions, depending on how they're implemented. Most `TypedData` are safe to free in parallel. The exceptions are those `free` functions that read or modify global state without locking. ### Examples ```c static void example_data_free(void *ptr) { st_delete(live_example_datas, (st_data_t*)&ptr, NULL); // Not thread-safe! } ``` If 2 of these `TypedData` objects are freed at the same time, this could corrupt the `st_table`. A lock must be held when manipulating this table. Because Ruby code can also run alongside a sweep worker, the lock must also be held when adding to or iterating this table. ```c rb_nativethread_lock_t example_data_lock; static void example_data_free(void *ptr) { rb_native_mutex_lock(&example_data_lock); st_delete(live_example_datas, (st_data_t*)&ptr, NULL); rb_native_mutex_unlock(&example_data_lock); } static void live_examples_add(void *ptr) { rb_native_mutex_lock(&example_data_lock); st_insert(live_example_datas, (st_data_t)ptr, (st_data_t)ptr); rb_native_mutex_unlock(&example_data_lock); } static void Init_example(void) { rb_native_mutex_initialize(&example_data_lock); } ``` If a CRuby developer or user wants to make their code compaction-safe, they don’t need to worry about parallel sweep workers because the workers don't run during compaction. ### Proposal I propose adding a new flag to `TypedData` that allows both CRuby developers and extension authors to opt-in to allow their `TypedData` type to be freed in parallel. It could be called something like `RUBY_TYPED_PARALLEL_FREE_SAFE`. In our branch where we are developing parallel sweeping, most `TypedData` internal to the VM are given this flag. I believe C extension authors would opt in as well if they see that parallel sweeping gives good performance benefits to Ruby applications. We would need to document what is safe and what is not safe inside these `free` functions for types that are marked with this bit. If the user needs to use a native mutex to protect their `TypedData` from being corrupted when freed in parallel, they must do so. However, if they lock this native mutex in non-free function code paths as well, they may not allocate objects or use `ruby_xmalloc` while this mutex is held. These are some examples of trickiness when it comes to concurrency in the Ruby VM. I believe having a section in the extension documentation about these types of free functions (or elsewhere such as the Concurrency Guide) would give CRuby developers and extension authors more confidence in adding this bit to their types. ### A possible future: parallel marking? If in the future CRuby gets parallel marking, we believe we probably would need another bit for `TypedData` so we can register them as parallel-mark safe. If that’s the case, it’s unfortunate that authors that want this feature would need to update their extension again with a new bit if this bit were to be made public. One could argue that we should have a single bit that indicates safety for both parallel freeing and parallel marking. However, we believe the specifics of what could and couldn’t be executed inside these `free` and `mark` functions would be too hard to work out today for a combined bit without locking us into a specific parallel marking implementation. ### Alternative We could not expose the parallel-free-safe bit to extension authors and only free internal `TypedData` objects in parallel. However, this does slow the current implementation of parallel sweeping down because even if one of these objects is on a heap page, the Ruby GC thread needs to further post-process the page after the sweep thread sweeps it. It would also limit further optimizations to parallel sweeping. ### Details of the bit Worker threads could only free `TypedData` objects that have this new bit set alongside the `RUBY_TYPED_FREE_IMMEDIATELY` bit. Otherwise, the Ruby GC thread must free them. Also, if the type has `0` or `RUBY_TYPED_DEFAULT_FREE`/`RUBY_DEFAULT_FREE` as the free function, it can be freed in parallel. ### Conclusion Parallel sweeping is being actively developed and adding this bit increases performance of the developing implementation of parallel sweeping. It allows `TypedData` types to be freed by worker thread(s), which decreases GC pause times. Since `TypedData` are also exposed to extension authors, we need to whitelist these types for parallel freeing, as not all of these functions are currently safe. By documenting what is and isn’t safe, extension authors can write correct `free` functions that are safe to be freed by worker threads. Alternatively, we could have this bit be internal to CRuby. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:124288] [Ruby Bug#21790] `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts
by adamoffat (Adam Moffat) 17 Jun '26

17 Jun '26

Issue #21790 has been reported by adamoffat (Adam Moffat). ---------------------------------------- Bug #21790: `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts https://bugs.ruby-lang.org/issues/21790 * Author: adamoffat (Adam Moffat) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby's `Socket.getaddrinfo` hangs indefinitely in forked child processes on macOS 26.1 (Tahoe) when resolving IPv4-only hostnames. This is a regression that does not occur on macOS 15.x (Sonoma) or earlier. **Ruby version:** ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin24] Also confirmed this affects Ruby 3.2.6 and 3.4.1. **Reproducible script:** ``` ruby require "socket" require "timeout" puts "Ruby #{RUBY_VERSION} on #{RUBY_PLATFORM}" Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) puts "Parent: DNS completed" pid = fork do puts "Child: Attempting DNS resolution..." begin Timeout.timeout(90) do Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) end puts "Child: SUCCESS" exit 0 rescue Timeout::Error puts "Child: FAILED - hung for 90 seconds" exit 1 end end Process.wait(pid) ``` **Note:** Remove the `Timeout.timeout(90)` wrapper to observe the hang indefinitely. The timeout is included only to allow the script to exit for testing purposes. **Result of reproduce process:** ``` Ruby 3.3.8 on arm64-darwin24 Parent: DNS completed Child: Attempting DNS resolution... Child: FAILED - hung for 90 seconds ``` The child process hangs with one thread consuming 100% CPU. Expected result: The child process should complete DNS resolution successfully, as it does on macOS 15.x and earlier. **Analysis:** Stack trace shows: Main thread: Blocked in `wait_getaddrinfo` → `_pthread_cond_wait` DNS thread: Spinning in `_gai_nat64_second_pass` → `nw_path_access_agent_cache` → `_os_log_preferences_refresh` → `SIGSEGV` The crash occurs in macOS's NAT64 synthesis code path. Ruby's signal handler catches the `SIGSEGV` but cannot recover, causing the DNS thread to spin. **Key observations:** - Only affects IPv4-only hosts. Hosts with IPv6 (like google.com) work correctly. - Using `AF_INET` instead of `AF_UNSPEC` works. `Socket.getaddrinfo("api.segment.io", 443, Socket::AF_INET, :STREAM)` succeeds. - Python is not affected. Python calls `getaddrinfo()` synchronously without a background thread. - Parent must do DNS before fork. If the parent has not called getaddrinfo(), the child works correctly. **Workaround:** - Use `resolv-replace` to bypass the native DNS resolver: `require "resolv-replace"` **Impact:** This breaks all Ruby applications using pre-forking worker models (Resque, Unicorn, Puma, Sidekiq, Passenger) on macOS Tahoe. **Apple Bug Report:** Filed with Apple as Feedback Assistant #FB21364061 ---Files-------------------------------- stack_trace.txt (66.6 KB) ruby_dns_fork_bug.rb (1.02 KB) -- https://bugs.ruby-lang.org/

2 9

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

16 Jun '26

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

6 11

[ruby-core:125276] [Ruby Bug#22003] .bundle extensions not built when doing out-of-source build
by Kulikjak (Jakub Kulik) 14 Jun '26

14 Jun '26

Issue #22003 has been reported by Kulikjak (Jakub Kulik). ---------------------------------------- Bug #22003: .bundle extensions not built when doing out-of-source build https://bugs.ruby-lang.org/issues/22003 * Author: Kulikjak (Jakub Kulik) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [amd64-solaris2.11] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi, I encountered a pretty edge case extension build bug. When building Ruby out-of-source and executing the configure script with a full path in a workspace that contains "test" in its name, it fails to build all the extensions in the `.bundle/gems` directory. It can be easily reporoduced with the following: ``` > pwd /builds/testing/components/ruby/ruby-40 > mkdir build > cd build > /builds/testing/components/ruby/ruby-40/ruby-4.0.2/configure ... > /usr/gnu/bin/make -j 20 ... <the stuff in the .bundle directory is not built> ``` When doing it this way, the `srcdir` variable in the Makefile will be an absolute path, which is then used in `ext/configure-ext.mk` target and in `configure-ext.mk.tmpl` `Dir.glob` call, where the following line: ``` % next if extconf.any?{|f| f.include?(".bundle/gems") && f.include?("test") } ``` makes it omit all the extensions in the ".bundle/gems" directory. The problem is not there when I use a relative path (`../ruby-4.0.2/configure`) or when building directly in `ruby-4.0.2` (because the `srcdir` is relative in those cases). -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125553] [Ruby Bug#22076] defined? returns nil for protected methods defined in a module even when callable
by sampokuokkanen (Sampo Kuokkanen) 14 Jun '26

14 Jun '26

Issue #22076 has been reported by sampokuokkanen (Sampo Kuokkanen). ---------------------------------------- Bug #22076: defined? returns nil for protected methods defined in a module even when callable https://bugs.ruby-lang.org/issues/22076 * Author: sampokuokkanen (Sampo Kuokkanen) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Filing this to confirm whether defined? should return "method" here (matching the call check), or whether the current nil behavior is intentional. ### Summary `defined?` returns `nil` for a protected method defined in a module, even when the same call succeeds. For a protected method defined in a class, `defined?` and the call agree. ### Reproduction ~~~ruby module Mix def secret; 42; end protected :secret end class A; include Mix; end class B include Mix def call_it(other) = other.secret def defined_it(other) = defined?(other.secret) end p B.new.call_it(A.new) # => 42 p B.new.defined_it(A.new) # => nil (expected "method") ~~~ The class-defined version returns `"method"` for the same shape: ~~~ruby class Base def secret; 42; end protected :secret end class A < Base; end class B < Base def defined_it(other) = defined?(other.secret) end p B.new.defined_it(A.new) # => "method" ~~~ ### Fix Use `rb_callable_method_entry_with_refinements` and the existing `vm_defined_class_for_protected_call` helper. Patch with test: (will update soon) ## Environment - MacOS Tahoe 26.2 - Ruby master (HEAD) - ruby 4.0.1 -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125543] [Ruby Bug#22074] YJIT misaligns locals when there are > 256 local variables
by ibrahima (Ibrahim Awwal) 14 Jun '26

14 Jun '26

Issue #22074 has been reported by ibrahima (Ibrahim Awwal). ---------------------------------------- Bug #22074: YJIT misaligns locals when there are > 256 local variables https://bugs.ruby-lang.org/issues/22074 * Author: ibrahima (Ibrahim Awwal) * Status: Open * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! We ran into this issue in production with a large Slim template in a Rails app, but we found that it's reproducible in any function with a lot of local variables. It seems like YJIT tracks local variables for register allocation in an 8-bit integer, so if there are more than 256 local variables in a function, the index overflows and maps back to the wrong variable and causes issues. We reproduced the issue with the released version of Ruby 4.0.4. We have a simple reproduction script and a proposed patch. The reproduction script generates some code with 257 locals and tests that it behaves correctly over multiple iterations (to exercise YJIT since it doesn't kick in right away). Full disclosure, the code is AI-written, and I don't know Rust, but I do know C and integer overflows, and it seems somewhat reasonable - though I'm not sure if it's the exact right fix. With YJIT disabled: ``` $ ruby yjit_many_locals_simple_repro.rb ruby=ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [x86_64-linux] yjit=false iterations=100000 YJIT is not enabled. Re-run with: ruby --yjit yjit_many_locals_simple_repro.rb iteration=10000 iteration=20000 iteration=30000 iteration=40000 iteration=50000 iteration=60000 iteration=70000 iteration=80000 iteration=90000 iteration=100000 ok iterations=100000 ``` With YJIT enabled ``` $ ruby --yjit yjit_many_locals_simple_repro.rb ruby=ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +YJIT +PRISM [x86_64-linux] yjit=true iterations=100000 failed_at=30 yjit_many_locals_simple_repro.rb:259:in 'Object#many_locals': undefined method '+' for an instance of Object (NoMethodError) from yjit_many_locals_simple_repro.rb:42:in 'block in <main>' from yjit_many_locals_simple_repro.rb:41:in 'Integer#times' from yjit_many_locals_simple_repro.rb:41:in '<main>' yjit_many_locals_simple_repro.rb:259:in 'Object#many_locals': undefined method '+' for an instance of Object (NoMethodError) from yjit_many_locals_simple_repro.rb:42:in 'block in <main>' from yjit_many_locals_simple_repro.rb:41:in 'Integer#times' from yjit_many_locals_simple_repro.rb:41:in '<main>' ``` Thank you for your consideration! ---Files-------------------------------- yjit_many_locals_simple_repro.rb (1.32 KB) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:125565] [Ruby Bug#22079] Float#ceil gives incorrect result
by cryptogopher (crypto gopher) 14 Jun '26

14 Jun '26

Issue #22079 has been reported by cryptogopher (crypto gopher). ---------------------------------------- Bug #22079: Float#ceil gives incorrect result https://bugs.ruby-lang.org/issues/22079 * Author: cryptogopher (crypto gopher) * Status: Open * ruby -v: ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Let's take following number as an example: ``` ruby > Float::MIN => 2.2250738585072014e-308 ``` This gives proper result: ```ruby > Float::MIN.ceil(308) => 2.9999999999999997e-308 ``` But this does not: ```ruby > Float::MIN.floor(309) => NaN ``` even though the result is perfectly valid `Float` number: ```ruby > "2.3e-308".to_f => 2.3e-308 ``` -- https://bugs.ruby-lang.org/

3 2