timo
timo
``` Thread 1 "rakudo-m" received signal SIGSEGV, Segmentation fault. 0x00007ffff78836c5 in copy_elements (tc=0x3943c020180, src=0x3943c1ca3c8, dest=0x3943c120970, s_offset=0, d_offset=0, elems=1) at src/6model/reprs/VMArray.c:864 864 MVMuint16 source_kind = slot_type_to_kind(s_repr_data->slot_type); [...] (gdb) list copy_elements 834...
compiled a fresh moar/nqp/rakudo, now the line for STORE is `SETTING::src/core.c/native_array.rakumod:933 (/home/timo/raku/prefix/share/perl6/runtime/CORE.c.setting.moarvm:STORE)`, i'm on `2024.05.6.g.5.c.10672.ca built on MoarVM version 2024.05.1.ga.7.b.452.e.53`, it looks like the code didn't change so my previous...
I just wrote this on IRC, I figured it should also be in this ticket: > we might actually be able to get away with doing a different change, however...
with just these changes, the moarvm CI run is now roughly at an average of 35 minutes, it was at roughly 45 minutes before.
added a section on identifying objects by paths from roots to the objects using the heap snapshot machinery to the end of the original post, inspired by a recent rakudo...
ran the example code from that same issue with CROSS_THREAD_WRITE_LOG and got these results: https://gist.github.com/timo/a938a7d4fb9f07bd008b3ba33e7b3f73 - verdict: at the moment extremely spammy with false positives from Lock::Async (likely caused by...