|
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
|
|||