09:02 apogee_ntv left 10:18 apogee_ntv joined, shareable6 left
apogee_ntv Hm, I think I've found a GC regression that's causing panics. Digging. 10:18
10:19 shareable6 joined
apogee_ntv Oh, looks like lizmat already reverted the root cause on main :D 10:30
lizmat I did?
apogee_ntv That was causing me a lot of nasty crashes on my coding harness, I thought it was something I did because my upgrade from 2026.03 coincided with a lot of Selkie rework stuff
github.com/MoarVM/MoarVM/commit/a7...0b3cbf180d Yeah this commit I think, when running concurrently it was causing crashes. 10:31
lizmat ah that one, right :-) 10:32
apogee_ntv Yeah I was running at 32 threads and just crashing constantly because of stale pointers
Pulled it down to 1 thread and couldn't get it to reproduce. 10:33
Was the reason for reversion similar? 10:39
lizmat not sure... I think it was just missing bytes.. 11:04
apogee_ntv lizmat: gist.github.com/m-doughty/ce5e7159...e51c26141b minimum repro, clean on main, lots of fails on 2026.08 (tested on MacOS, M4 Max). I stopped digging because its fixed on main but looks like we're doing thread-unsafe work when another thread collects for a thread which is GC blocked -- specifically stuff in temproots is getting changed even when the thread is marked _UNABLE 12:08
in its gc_status.
So if we reintroduce similar code we should probably check it against this reproducer. 12:09
lizmat could you add that as a comment to the commit that reverted the fix that produced this error? 12:10
apogee_ntv Yes
lizmat thanks!
hopefully it won't fall through the cracks then
apogee_ntv Comment added to github.com/MoarVM/MoarVM/commit/a7...0b3cbf180d with a cleaned up version of my investigative notes. 12:25
lizmat apogee_ntv++ 12:28
apogee_ntv I did note a couple of other sites where the issue could exist btw, I have not confirmed. 12:40
13:59 rakkable left 14:00 rakkable joined 14:37 Geth__ joined 14:40 Geth left 16:13 Geth__ left 16:14 Geth joined 16:21 Geth left, Geth joined