The interrupt check will unintentionally release the VM lock when loading an iseq. And this will cause issues with the debug gem's ObjectSpace.each_iseq method, which wraps iseqs with a wrapper and exposes their internal states when they're actually not ready to be used.
And when that happens, errors like this would occur and kill the debug gem's thread:
A large amount of iseq being loaded from another thread (possibly through the bootsnap gem).
1 and 2 iterating through the same iseq(s) at the same time.
Because this issue requires external dependencies and a rather complicated timing setup to reproduce, I wasn't able to write a test case for it. But here's some pseudo code to help reproduce it:
Avoid checking interrupt when loading iseq
The interrupt check will unintentionally release the VM lock when loading an iseq.
And this will cause issues with the
debuggem'sObjectSpace.each_iseqmethod,which wraps iseqs with a wrapper and exposes their internal states when they're actually not ready to be used.
And when that happens, errors like this would occur and kill the
debuggem's thread:A way to reproduce the issue is to satisfy these conditions at the same time:
debuggem callingObjectSpace.each_iseq(e.g. activating aLineBreakpoint).bootsnapgem).Because this issue requires external dependencies and a rather complicated timing setup to reproduce, I wasn't able to write a test case for it.
But here's some pseudo code to help reproduce it:
[Bug #19348]
Co-authored-by: Peter Zhu peter@peterzhu.ca