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.
Nicholas good *, * 07:42
nine Beautiful *, #moarvm 10:04
nine I've finally managed to confirm my hypothesis that the crashes in the GC that I can reproduce with LibXML's t/90threads.t are caused by native call sites getting cloned while a different thread is still in the process of initializing them 16:00
jdv sounds scary 16:02
nine The copy_to call itself is triggered by a getattr_o op
Ironically the getattr_o access is to check whether the callsite is setup yet or not 16:09
Geth MoarVM: 207db4bb5b | (Stefan Seifert)++ | 2 files
Fix segfaults due to race condition when initializing native call sites

Ensure that a native callsite's arg_types and arg_info arrays are fully populated before the body's pointers to them are assigned. Otherwise another thread may copy uninitialized data as part of a copy_to operation (probably triggered by getattr_o).		 17:41
nine Over an hour of having 27 loops run 90threads.t and not a single failure :) 17:42
Sadly that has to be with MVM_JIT_EXPR_DISABLE=1 du to the known racy code the expr jit creates. 17:43
But at least we can be reasonably sure that no other bug affects this test (and thus LibXML) anymore :)
[Coke] nine++ 17:44
me: Maybe I can hack on stuff during my break! also me: Hey, let's my booster shot right before break!
lizmat jdv nine time for a MoarVM bump ? 17:45
Geth MoarVM: 768228b327 | (Stefan Seifert)++ | 2 files
Fix return register staying uninitialized on dispatch to void native functions

This got lost when turning nativecall_invoke into nativecall_dispatch. Even if the native function itself doesn't return a result (i.e. void), we have to set the call's result to something as in general the call will be initiated through dispatch_o which is expected to return an object. NativeCall convention is to return a type object in this case. So follow the convention		 17:46
MoarVM: fd6a41035e | (Stefan Seifert)++ | src/spesh/disp.c
Fix uninitialized return register on translated calls to void native functions

We optimize calls to native functions without return values (i.e. void) to sp_runnativecall_v. Nevertheless we have to initialize the original target register with something (i.e. the return value type object), because the register may be read after a deopt. This is all the more likely as a guard on the return register would trigger a deopt if the register contains a NULL value.
Fixes segfaults after deopts after void native calls.
MoarVM: 69c9452953 | niner++ (committed using GitHub Web editor) | 3 files
Merge pull request #1622 from MoarVM/fix_segfault_with_void_native_calls

Fix segfault with void native calls
MoarVM: f0e4b08c09 | (Stefan Seifert)++ | src/core/args.c
Fix possible access to fromspace when autoboxing return values

If the target frame (e.g. tc->cur_frame) is a heap frame that lives in the nursery, the return value is a native value (e.g. return_i or a native call), the caller expects an object and boxing happens to trigger a GC run, the target frame could be moved before we dereference the target pointer to get the return_value register. This would lead to a segfault with GC_DEBUG 3. ... (5 more lines)		 17:47
MoarVM: 2914410fa7 | niner++ (committed using GitHub Web editor) | src/core/args.c
Merge pull request #1624 from MoarVM/fix_autoboxing_gc_issue

Fix possible access to fromspace when autoboxing return values
nine lizmat: now's probably a better time :)
lizmat I see :-)
jdv are you ok with that? 17:48
nine I figured better to get these merged and exercised rather than wait longer for a review. The review can still be done post-facto
lizmat nine: or do you think these should be in a release anyway ?
nine They absolutely need to be in the next release 17:52
lizmat ok, I will bump now 17:54
jdv fun stuff 18:00
lizmat nine: github.com/rakudo/rakudo/pull/4676 ?? 18:23
jdv nice catch. i was about to ask about that one. 18:27
lizmat afk for dinner& 18:31
MasterDuke nine: nice fixes. did that dyncall fix also end up making it into ffi? 19:58
dogbert17 nine++, does this mean that MoarVM is now officially bug free :) 20:29

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!