Issue #19364 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Closed Re-checked on master 4d185cce78 with a RUBY_DEBUG=1 build: the script in the description runs clean, 30 times out of 30. The cause you named -- "changing iseq internals is done without the VM lock" -- has been addressed. `rb_tracepoint_enable_for_target()` in vm_trace.c now stops the world before rewriting the iseq: RB_VM_LOCKING() { // Rewriting iseq instructions across ractors is not safe unless they are stopped. rb_vm_barrier(); ... ---------------------------------------- Bug #19364: Issue with tracepoint enable/disable across ractors https://bugs.ruby-lang.org/issues/19364#change-118838 * Author: luke-gru (Luke Gruber) * Status: Closed * Assignee: ractor * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This sometimes segfaults: ```ruby def test_enable_disable_in_multiple_ractors_with_target rs = [] 100.times do |i| # setup new iseqs Kernel.define_method :"my_method_to_change_for_tracing_#{i}" do true end end 100.times do |i| rs << Ractor.new(i) do |j| meth = :"my_method_to_change_for_tracing_#{j}" tp = TracePoint.new(:line) { } # local to ractor 100.times do tp.enable(target: method(meth)) # change iseq internals of given method, should be done with lock tp.disable # disable hooks should hold lock too, changes method definition internals end end end rs.each(&:take) # shouldn't raise end test_enable_disable_in_multiple_ractors_with_target() ``` Changing iseq internals is done without the VM lock. This is true in Tracepoint#enable and Tracepoint#disable methods. I have a patch coming. -- https://bugs.ruby-lang.org/