Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 01:04 reportable6 joined 01:12 psydroid joined 02:12 AlexDaniel joined 04:17 sourceable6 left, releasable6 left, reportable6 left, statisfiable6 left, bisectable6 left, linkable6 left, squashable6 left, nativecallable6 left, benchable6 left, committable6 left, greppable6 left, bloatable6 left, coverable6 left, unicodable6 left, shareable6 left, quotable6 left, tellable6 left, evalable6 left, notable6 left, greppable6 joined 04:18 shareable6 joined, linkable6 joined, committable6 joined, benchable6 joined, quotable6 joined, sourceable6 joined 04:19 statisfiable6 joined, notable6 joined 04:20 bloatable6 joined 05:18 bisectable6 joined 05:19 tellable6 joined, releasable6 joined 05:20 squashable6 joined 06:18 unicodable6 joined 06:19 evalable6 joined 07:06 reportable6 joined 07:20 coverable6 joined
nine What I've found out so far: that oops happens because the inline cache entry was freed already when it got replaced by MVM_disp_inline_cache_transition in a different thread. 08:41
So multiple threads are working at the same callsite. One thread is kinda in the middle of an elaborate dispatch when the GC gets triggered. The other thread was a bit faster and finished recording a dispatch program. 08:46
When finishing recording, we update the inline cache entry scheduling the previous version to be freed at a safe point 08:47
That old cache entry however is still pointed to by a callstack record in the other thread. 08:49
I fear this will need jnthnwrthngtn to fix, as the proper course of action is anything but clear. There is a fix/workaround for this specific case, since we can detect the situation reliably (ic_entry_ptr does not point at ic_entry), but freeing a cache entry that's still pointed at by a callstack sounds like a recipie for desaster 09:05
Memory management in multi threaded programs is hard
Btw. to reproduce, set nursery size to something small like 6K and then while rr record /home/nine/rakudo/install/bin/moar --execname=/home/nine/rakudo/rakudo-m --libpath=/home/nine/rakudo --libpath=/home/nine/rakudo/blib --libpath=/home/nine/rakudo/install/share/nqp/lib /home/nine/rakudo/rakudo.moarvm -e 'await (^5).map({start { print qqx{echo $_} } })' ; do true ; done 09:07
10:18 nativecallable6 joined 10:37 frost-lab joined
nine I created an issue for this, so the information does not get lost: github.com/MoarVM/MoarVM/issues/1529 10:45
10:45 frost-lab left 11:24 sena_kun joined 12:02 reportable6 left
dogbert17 hmm, I don't think we have any more bugs atm 12:16
dogbert17 starts looking ... 12:19
sena_kun dogbert17, there are still 180 tickets opened. :P 12:20
dogbert17 sena_kun: true, but atm I'm concentrating on new-disp 12:22
we need to give nine++ something to do :) 12:23
[Coke] Still have the windows nativecall failures when run simultaneously 12:25
I haven't figured out yet how to get one of those failures to show up in the debugger so we can figure it out
14:53 squashable6 left 14:54 squashable6 joined 15:04 reportable6 joined 17:42 sena_kun left 17:55 ilogger2 left 17:56 ilogger2 joined 18:02 reportable6 left 20:07 harrow left, harrow joined 20:39 MasterDuke58 left 21:45 MasterDuke joined