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

[ruby-core:123883] [Ruby Feature#21704] Expose rb_process_status_new to C extensions
by noteflakes (Sharon Rosner) 09 Jul '26

09 Jul '26

Issue #21704 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21704: Expose rb_process_status_new to C extensions https://bugs.ruby-lang.org/issues/21704 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_new` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:124833] [Ruby Bug#21882] IO::Buffer#locked leaves the buffer locked when the block raises
by hanazuki (Kasumi Hanazuki) 09 Jul '26

09 Jul '26

Issue #21882 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21882: IO::Buffer#locked leaves the buffer locked when the block raises https://bugs.ruby-lang.org/issues/21882 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `IO::Buffer#locked` should unlock the buffer even after the block raises an exception. ```ruby buf = IO::Buffer.new(100) buf.locked { fail } rescue nil buf.locked { p :ok } # expected to print :ok, but actually raises a LockedError ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:123795] [Ruby Bug#21685] Unnecessary context-switching, especially bad on multi-core machines.
by jpl-coconut (Jacob Lacouture) 09 Jul '26

09 Jul '26

Issue #21685 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21685: Unnecessary context-switching, especially bad on multi-core machines. https://bugs.ruby-lang.org/issues/21685 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the benchmark takes ~3.6sec on a single-core machine, and ~36sec **(10x slower) on a machine with 2 or more cores** . Initially I thought this was a bug in the implementation of Thread::Queue, but soon realized it relates to how the ruby reschedules threads around system calls. I prepared a fix in [[this branch]](https://github.com/jpl-coconut/ruby/tree/deferred_thread_wait) which is based off ruby 3.4.7. I can apply the fix to a different branch or to master if that's helpful. The fix simply defers suspending the thread until the syscall has been running for some short interval. I chose 100usec initially, but this could easily be made configurable. I pasted raw benchmark results below from a single run (though I did many runs and the results are stable). My CPU is an Apple M4. After the fix: - Single-core performance improves by 55%, from 3.6sec to 2sec. - Adding cores causes performance to be flat (at 2sec), rather than getting 10x slower. - Multi-core context-switch count reduces by 99.995%, from 1.4 million to ~80 - system_time/user_time ratio drops from (1.2 - 1.6) to 0.65 Here are the benchmark results before my change: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1140773 nonvoluntary_ctxt_switches: 9487 real 0m3.619s user 0m1.653s sys 0m1.950s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1400110 nonvoluntary_ctxt_switches: 3 real 0m36.223s user 0m9.380s sys 0m14.927s ``` And after: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 88 nonvoluntary_ctxt_switches: 899 real 0m2.031s user 0m1.209s sys 0m0.743s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 75 nonvoluntary_ctxt_switches: 8 real 0m2.062s user 0m1.279s sys 0m0.783s ``` I was concerned these results might still be reflective of a bug in Thread::Queue, so I also came up with a repro that doesn't rely on it. That one is [[here]](https://gist.github.com/jpl-coconut/aa14e59354abf98f808daaf39baa9a72). Results summary: - Single-core performance improves (this time by only 30%) - Multi-core penalty drops from 4x to 0. - No change to context-switching rates. - system_time/user_time ratio drops from (0.5-1) to 0.15 Before fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.336s user 0m0.211s sys 0m0.118s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m1.424s user 0m0.468s sys 0m0.496s ``` After fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 59 real 0m0.241s user 0m0.202s sys 0m0.032s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.238s user 0m0.195s sys 0m0.035s ``` -- https://bugs.ruby-lang.org/

7 18

[ruby-core:125071] [Ruby Feature#21957] Introduce `Enumerable#close` to free internal resources.
by ioquatix (Samuel Williams) 02 Jul '26

02 Jul '26

Issue #21957 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #21957: Introduce `Enumerable#close` to free internal resources. https://bugs.ruby-lang.org/issues/21957 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- In some cases, `Enumerable` has substantial internal state (e.g. Fiber) related to enumeration. There is currently no way to clear up this state besides garbage collection, which means that we can accumulate considerable garbage before cleaning up, even if we know when the enumerable is no longer needed. I'd like to introduce `Enumerable#close` which invalidates the enumerable, freeing internal resources. After which, most usage would result in `Enumerable::ClosedError`. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115879] [Ruby master Bug#20081] Transfered Fiber doesn't return to Fiber that started it
by rmosolgo (Robert Mosolgo) 01 Jul '26

01 Jul '26

Issue #20081 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #20081: Transfered Fiber doesn't return to Fiber that started it https://bugs.ruby-lang.org/issues/20081 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi! I'm trying to figure out how to make sure that Fibers started with `.transfer` end up _terminated_, not just suspended. (If they're suspended, Rails thinks they're still alive, and they continue to hold onto database connections, see: https://github.com/rmosolgo/graphql-ruby/issues/4739#issuecomment-1866930914.) So, I'm looking for way to make sure that any Fiber I start with `.transfer` will be properly terminated. But what I noticed is that when a transfer-based Fiber terminates, it gives control back to the top-most Fiber, not the Fiber which transfered to it. Is this intended? Here's a script to replicate the issue: ```ruby manager = Fiber.new do parent = Fiber.current worker = Fiber.new do puts "2. Begin Worker" parent.transfer puts "4. End Worker" end puts "1. Transfer 1" worker.transfer puts "3. Transfer 2" worker.transfer puts "5. Finished manager" end manager.transfer puts "6. Finished script" ``` I expect the steps to print in order: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 5. Finished manager 6. Finished script ``` But instead, `5. ...` is skipped: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 6. Finished script ``` I think that's because my `worker` fiber terminates and passes control back to the top-level Fiber. Should it have passed control back to the `manager`? Or is there another way to make sure `worker` is terminated, and `manager` gets control? -- https://bugs.ruby-lang.org/

3 9

[ruby-core:125150] [Ruby Bug#21970] Corrupted `ciobj->operands` in `compile.c: optimize_checktype`
by byroot (Jean Boussier) 30 Jun '26

30 Jun '26

Issue #21970 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21970: Corrupted `ciobj->operands` in `compile.c: optimize_checktype` https://bugs.ruby-lang.org/issues/21970 * 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 ---------------------------------------- A rare crash I observed in production. I unfortunately don't have a reproduction, but perhaps this will ring a bell to someone. ``` #4 0x0000aaaac9afb1b8 [PAC] in sigsegv (sig=11, info=0xaaaaff573e30, ctx=0xaaaaff573eb0) at signal.c:948 #5 <signal handler called> #6 0x0000aaaac9ddcb60 in get_next_insn (iobj=0xffffffff00000001) at compile.c:3078 #7 optimize_checktype (iobj=0xaaab00000640, iseq=0xffff6e41ac80) at compile.c:3291 #8 iseq_peephole_optimize (iseq=iseq@entry=0xffff6e41ac80, list=list@entry=0xaaab00000640, do_tailcallopt=do_tailcallopt@entry=0) at compile.c:3363 #9 0x0000aaaac9dde590 [PAC] in iseq_optimize (anchor=<optimized out>, iseq=<optimized out>) at compile.c:4453 #10 iseq_setup_insn (anchor=<optimized out>, iseq=<optimized out>) at compile.c:1648 #11 iseq_setup_insn (iseq=0xffff6e41ac80, anchor=0xffffdb42d078) at compile.c:1637 #12 0x0000aaaac9e22d34 [PAC] in pm_iseq_compile_node (iseq=0xffff6e41ac80, node=<optimized out>) at /ruby-4.0.2/prism_compile.c:10514 #13 0x0000aaaac9a32f08 [PAC] in pm_iseq_new_with_opt_try (d=d@entry=281474360333120) at iseq.c:1106 #14 0x0000aaaac99c81bc [PAC] in rb_protect (proc=proc@entry=0xaaaac9a32eec <pm_iseq_new_with_opt_try>, data=data@entry=281474360333120, pstate=pstate@entry=0xffffdb42d3e4) at eval.c:1127 #15 0x0000aaaac9a39408 [PAC] in pm_iseq_new_with_opt (node=node@entry=0xffffdb42d510, name=name@entry=281472546599520, path=path@entry=281472531544280, realpath=281472531544280, first_lineno=first_lineno@entry=215, parent=parent@entry=0x0, isolated_depth=isolated_depth@entry=0, type=type@entry=ISEQ_TYPE_METHOD, option=0xffffdb42d328, error_state=error_state@entry=0xffffdb42d3e4) at iseq.c:1159 #16 0x0000aaaac9dcf1fc [PAC] in pm_new_child_iseq (iseq=iseq@entry=0xffff6e41b068, node=node@entry=0xffffdb42d510, name=281472546599520, parent=parent@entry=0x0, type=type@entry=ISEQ_TYPE_METHOD, line_no=215) at /ruby-4.0.2/iseq.h:154 #17 0x0000aaaac9e0688c [PAC] in pm_compile_node (iseq=iseq@entry=0xffff6e41b068, node=0xaaab000f0ac0, ret=ret@entry=0xffffdb42dcd8, popped=popped@entry=true, scope_node=scope_node@entry=0xffffdb42e170) at /ruby-4.0.2/prism_compile.c:9073 #18 0x0000aaaac9e0bd7c [PAC] in pm_compile_node (iseq=iseq@entry=0xffff6e41b068, node=0xaaab000eeed0, ret=ret@entry=0xffffdb42dcd8, popped=popped@entry=false, scope_node=scope_node@entry=0xffffdb42e170) at /ruby-4.0.2/prism_compile.c:10327 #19 0x0000aaaac9e1ee4c [PAC] in pm_compile_scope_node (iseq=iseq@entry=0xffff6e41b068, scope_node=scope_node@entry=0xffffdb42e170, ret=ret@entry=0xffffdb42dcd8, popped=popped@entry=false, node_location=<optimized out>, node_location=<optimized out>) at /ruby-4.0.2/prism_compile.c:7047 ``` ``` (gdb) f 7 #7 optimize_checktype (iobj=0xaaab00000640, iseq=0xffff6e41ac80) at compile.c:3291 3291 ciobj = (INSN *)get_next_insn((INSN*)OPERAND_AT(ciobj, 0)); (gdb) p (INSN*)ciobj->operands[0] $7 = (INSN *) 0xffffffff00000001 (gdb) p *(INSN*)ciobj->operands[0] Cannot access memory at address 0xffffffff00000001 ``` -- https://bugs.ruby-lang.org/

2 4

[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: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