Bug #22217: Segmentation fault when resuming execution with `Coverage.start` and ruby/debug

• Status: Closed
• Assignee: luke-gru (Luke Gruber)
• Target version: 4.0
• ruby -v: ruby 4.1.0dev (2026-07-29T23:49:57Z master 94933bfebf) +PRISM [arm64-darwin25],ruby 4.1.0dev (2026-07-29T23:49:57Z master 94933bfebf) +PRISM [x86_64-linux],ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25],ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux]
• Backport: 4.0: REQUIRED

[yokomaru (Yoko Suzuki)]

Resuming execution from ruby/debug while coverage collection is enabled via Coverage.start can cause a segmentation fault and crash the Ruby process.

The crash is intermittent, but reproduces frequently using the same steps. I confirmed it on both macOS (arm64) and Linux (x86_64) using debug 1.11.1. It reproduced with Ruby 4.0.5, Ruby 4.0.6, and Ruby 4.1.0-dev, but did not reproduce in my limited testing with Ruby 3.4.10 or Ruby 3.3.12.

Reproduction Code

test.rb

require "coverage"

Coverage.start

require "debug"

debugger

Steps to Reproduce

Run:

$ ruby test.rb

At the debugger prompt, enter:

continue

The same crash also occurs with next, step, and finish.

Backtrace Excerpt

Both macOS and Linux crash around the Ruby VM event hooks.

On macOS (arm64), the C-level backtrace includes:

libruby.4.1.dylib(exec_hooks_protected+0xb0)
libruby.4.1.dylib(rb_exec_event_hooks+0x7c)
libruby.4.1.dylib(vm_trace_hook+0x198)
libruby.4.1.dylib(vm_trace+0x24c)

On Linux (x86_64), it includes:

libruby.so.4.1(exec_hooks_body+0x20) vm_trace.c:453
libruby.so.4.1(exec_hooks_protected+0x10b) vm_trace.c:515
libruby.so.4.1(rb_exec_event_hooks+0x83) vm_trace.c:562
libruby.so.4.1(vm_trace_hook+0x17c) vm_core.h:2376
libruby.so.4.1(vm_trace+0x344) vm_insnhelper.c:7373

I've attached the crash log from the latest version (4.1.0-dev).

[luke-gru (Luke Gruber)]

• Assignee set to luke-gru (Luke Gruber)

[luke-gru (Luke Gruber)]

• Target version set to 4.0
• Backport changed from 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN to 4.0: REQUIRED

Thanks for the report and minimal repro, it was very helpful. I have a PR. This will be fixed in 4.0.7 (released some time in September). The affected version are 4.0.0 - 4.0.6.

• Status changed from Open to Closed

Applied in changeset git|6d14ea1306c8bbdea9b7eccbf0b91fa84bacec68.

---

Fix "oneshot" tracepoints that disable themselves during the hook

The debug gem uses a TP that disables itself (tp.disable) during the hook. If there are other
tracepoint events afterwards on the same iseq that share the same local hooks list, this results
in a UAF of the hook list.

This was fixed in a687756284187887835aa345adc89b2718054e4a but my patch for ractor-local Tracepoints
(4fb537b1ee28bb37dbe551ac65c279d436c756bc) reintroduced the bug. I added some more tests to make sure
this doesn't get reintroduced again in the future if someone does another rewrite/refactor.

Fixes [Bug #22217]

[luke-gru (Luke Gruber)]

Backport PR.

[yokomaru (Yoko Suzuki)]

Thank you so much for the quick fix and for preparing the backport!