> I would like to have an additional "sweep thread" that sweeps alongside the Ruby GC thread (in parallel) and at the same time as Ruby code is running (concurrent). When the sweep thread is working alongside the Ruby GC thread, both thr...ko1 (Koichi Sasada)
In the call branch of `curry`, `passed` is the only reference keeping the freshly built argument array alive, yet its backing buffer is handed to `rb_proc_call_with_block` as `argv` via `RARRAY_CONST_PTR(passed)`. After taking that point...ko1 (Koichi Sasada)
rb_gc_event_hook() ran hooks on rb_gc_get_ec(), which during GC returns the GC's snapshot (objspace->vm_context.ec, captured at marking). When a lazy sweep is continued from another thread's allocation, that snapshot belongs to the marki...ko1 (Koichi Sasada)
rb_vm_bugreport() silently skipped the control frame information, Ruby level backtrace, and threading sections when vm or ec was NULL, so the report jumped straight to the machine register context with no explanation of why no Ruby level...ko1 (Koichi Sasada)
## `Proc#curry` produces a corrupted (`false`) argument under GC compaction ### Summary The `Proc#curry` rubyspec example *"combines arguments and calculates incoming arity accurately for successively currying"* (`spec/ruby/core/pr...ko1 (Koichi Sasada)
rb_gc_register_mark_object() called rb_gc_impl_pointer_to_heap_p() without holding the VM lock. The lookup bsearches over objspace->heap_pages.sorted, but another ractor allocating heap pages mutates the darray (rb_darray_insert_without_...ko1 (Koichi Sasada)