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.
Geth MoarVM/new-disp-nativecall: d09757817a | (Stefan Seifert)++ | src/core/nativecall_dyncall.c
Fix segfaults when primitive parameters are passed to native function

The dispatcher calling convention allows for unboxed values to get passed to a native function. Need to handle those in MVM_nativecall_dispatch instead of blindly assuming that we always get objects.		 07:59
MasterDuke heh. i set a watchpoint on spesh_cand->body.jitcode when i hit the segfault. then i reverse-continued. `Old value = (MVMJitCode *) 0xffffffff00000005`, `New value = (MVMJitCode *) 0x5`. somehow neither of those value strike me as correct... 08:00
nine where does it get written_ 08:03
MasterDuke MVM_sc_set_collectable_sc
nine And it's quite possible that it gets overwritten multiple times.
That sounds like it got freed and the memory gets reused.
MasterDuke it does. reverse-continue again and it goes from 0x5 to 0x0 08:04
missing an MVM_ASSIGN_REF somewhere? 08:05
nine That or an MVMROOT 08:06
MasterDuke this looks like it was never set correctly and just gets randomly overwritten a couple times 08:07
and then eventually causes problems because of an `if (spesh_cand->body.jitcode) { ... }` 08:08
i'm guessing the problem is that i haven't correctly and/or fully adapted for the invoke->dispatch change 08:10
since this was pretty heavily tested before and made it through all builds, spectests, etc 08:11
nine With the latest rakudo commits, both rakudo's and Inline::Perl5's make test passes :) 08:41
And thanks to new-disp's architecture, supporting explicitly managed strings and Proxies does not cost any measurable performance :) 08:44
MasterDuke very cool
nine Next step will probably be to move unboxing from the VM to the dispatch program 09:03
The above commit was already a first step into that direction. Up to that NativeCall only allowed for boxed values and insisted on unboxing in the VM. Except for the JITed native calls which required unboxed values (accounting for much of the code in the generated function bodies. 09:05
nine I fear, this requires dispatch program ops that don't exist yet. 10:51
nine I thought that for unboxing I could just grab an Int's $!value attribute. But that is a bigint which we can't use directly as a native value. 10:55
Nicholas nine: ASAN is bored by your fixes. 11:09
nine Nothing like a boring Sunday :) 11:10
jnthnwrthngtn nine: I think we'll probably want to introduce dispatcher-track-unbox-[int|num|str], which will usually do the same as dispatcher-track-attr on objects, but can also result in different dispatch ops (and imply type/concreteness guards like attribute tracking does) 14:02
Also: yay, it's a further nice win that if one is dealing in native types, we can now easily end up with them never having to get boxed during the native calling process :) 14:03
nine jnthnwrthngtn: ah, thanks! Good to know that I'm on the right track. Will work on those dispatcher-track-unbox-[int|num|str] syscalls then 14:08
jnthnwrthngtn nine++ 14:26
jnthnwrthngtn is away for most of the rest of the day
jnthnwrthngtn is away for most of the rest of the day 14:27
nine Woohoo...dispatcher-track-unbox-int is working on P6opaque :) NativeRef apparently needs different handling, but it's a huge step forward 16:53
lizmat nine++ 16:56
nine Well for one we simply must not unbox rw args. But there seem to be other cases where IntLexRef appears 20:24
timo yeah it comes up whenever the caller can't know if the target takes rw or not and you have a native int locally 20:27
nine The dispatch program ought to know. But how can I check if I've got a NativeRef and how can I unbox it? I can check that in the VM but that just feels wrong 20:32
timo not sure how to properly check; you can do a reprid comparison. it should also iscontrw or whatever we have for that, and something something primsec 20:39
japhb .ask samcv_ or anyone who knows Unicode well: If I concatenate two strings $a = ($b ~ $c), I know MoarVM will apply renormalization around the join point, but 1) Can this cause a change in any character left of the join point *other* than the very last character? 2) Is there a fast way to definitively tell by looking at $c whether renormalization will cross the boundary? 3) Are there any combining 23:46
tellable6 japhb, I'll pass your message to samcv
japhb characters that won't combine under NFG?
jnthnwrthngtn At the time I first did NFG I'm pretty sure the answer to 1 had to be "no" because "boundary or not" was a property of two consecutive codepoints. However, I think a later version of Unicode made it more complicated than that (but samcv++ implemented that, not me, and I forget the details). 23:51
That said, I'm not sure it made looking at the last grapheme insufficient 23:53
github.com/MoarVM/MoarVM/blob/d11b...nfg.c#L398 is where we try to avoid a full renormalization 23:55
I think the complexity involved here means the answer to 2 is "no" :) 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!