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 00:04 reportable6 joined 00:14 linkable6 joined 00:56 frost joined 02:22 ggoebel left 03:39 linkable6 left, quotable6 left, greppable6 left, statisfiable6 left, reportable6 left, evalable6 left, squashable6 left, bisectable6 left, notable6 left, sourceable6 left, committable6 left, nativecallable6 left, benchable6 left, coverable6 left, shareable6 left, tellable6 left, unicodable6 left, releasable6 left, bloatable6 left, nativecallable6 joined, tellable6 joined, benchable6 joined, notable6 joined 03:40 statisfiable6 joined, sourceable6 joined, committable6 joined 03:42 reportable6 joined, bisectable6 joined, shareable6 joined 04:39 releasable6 joined, evalable6 joined 04:42 linkable6 joined, coverable6 joined, unicodable6 joined 05:39 bloatable6 joined 05:40 MasterDuke left 05:41 quotable6 joined, squashable6 joined 06:02 reportable6 left 06:03 reportable6 joined
Nicholas good *, #moarvm 06:04
07:12 MasterDuke joined 07:41 greppable6 joined
jnthnwrthngtn moarning o/ 09:12
Nicholas \o
lizmat morning! 09:25
09:29 linkable6 left, evalable6 left
MasterDuke hey hey. has anyone else been able to get the gcc plugins running recently? 09:31
09:34 Kaiepi left, Kaiepi joined
dogbert17 jnthnwrthngtn: I found nothing more than what I have already posted in the issue 10:21
my suggestion is that we try to 'sell' the issue to nine++ 10:22
Nicholas how much coffee do you have to offer?
dogbert17 now that's a good question
did jnthnwrthngtn get some good sleep last night? 10:23
nine has a knack for (root)ing out garbage bugs 10:24
jnthnwrthngtn I slept much better, yes 10:30
dogbert17 yay, and have you had som coffee?
jnthnwrthngtn Although one good night doesn't entirely make up for a few bad ones.
Yup, onto the second cup already :)
dogbert17 not bad :) 10:31
10:31 evalable6 joined 10:33 ggoebel joined
dogbert17 any opts/bugfixes planned? 10:33
jnthnwrthngtn Might look at the GC one in a bit. Currently working on my VMIL talk, which is already next week 10:41
nine I've had a look at the GC issue this morning, but so far not much success. It stumbles over a pointer getting interpreted as sc_idx. The pointer gets written during an assignment to an object attribute during deserialization. But the object in the worklist is a slot in an array. 10:43
11:05 ggoebel left 11:27 squashable6 left 12:02 reportable6 left 12:03 reportable6 joined
[Coke] is already moving on to cold caff, only one hot one today. 13:28
13:32 linkable6 joined 13:41 squashable6 joined 13:53 frost left
nine MVM_GC_DEBUG 3 does _not_ trigger the issue any sooner 15:08
15:22 vrurg left 16:01 colemanx left
Nicholas "sooner" is relative with MVM_GC_DEBUG *3* isn't it? 16:07
16:08 psydroid left, AlexDaniel left 16:12 AlexDaniel joined
dogbert17 nine: I've tried that as well. The only 'new' piece of information that I can provide is that the bug is not new. 16:15
16:15 psydroid joined
dogbert17 trying the example on 2021.06 led to a SEGV as well 16:17
nine That _is_ useful information 16:52
17:20 vrurg joined 18:02 reportable6 left, reportable6 joined
nine So this object in the array slot that gets it's header overwritten by the argument deserialization got allocated in gen2 directly (also due to deserialization) and till the crash never got freed. That's assuming that if it'd got freed, it would get the MVM_CF_DEBUG_IN_GEN2_FREE_LIST flag set, which according to my reading of the code must happen. 18:38
The object in question is a Sub that gets mixed into, moved around a bit to other SCs, then even repossessed. All fair game, but then it gets corrupted by set_obj_at_offset. Looking at the object that we're trying to set an attribute of, I actually see the same: 18:48
$34 = {header = {sc_forward_u = {forwarder = 0x16729090, sc = {sc_idx = 376606864, idx = 0}, st = 0x16729090}, owner = 1, flags1 = 0 '\000', flags2 = 2 '\002', size = 120}, st = 0x32ea380} 18:49
So again a pointer got written where the object's header should be (the forwarder that shouldn't be in use according to the flags). And the st is actually identical to the Sub I was tracking!
I think it's a confusion about object size. Possibly related to mixins and/or repossession 19:08
Indeed! The very first corruption happens during deserialization of yet another Sub+{Precedence} mixin. We're at MVM_ASSIGN_REF(tc, &(root->header), *((MVMObject **)location), value); 19:11
location points to the place 120 bytes from the start of root. Which according to root->st should be fine, as the size is 128 bytes. But root itself is only 120 bytes large. 19:12
And just to be sure I checked and it gets allocated by: MVM_gc_gen2_allocate_zeroed (al=0x16756e0, size=120) 19:13
And these 120 bytes are taken from Sub's ST. So yes, this is very much about mixins. 19:14
MasterDuke seems like another thing that is surprising it hasn't cropped up before
nine And yes, there's our final player arriving on stage: the mixin object's body.replaced gets cleared by repossession. So now we have a P6opaque with an st claiming that it's larger than it is and without a body replacement that would accomodate the additional story 19:22
During repossession there would even be a chance to get back into change_type which would allocate that replacement body. But we don't since updated_st == orig_obj->st 19:24
Seems to me that P6opaque's deserialize should take care of this situation. If there's no replaced body and the st's size field differs from the object's allocated size, allocate a replacement body. 19:30
[Coke] nice detective work
nine And indeed that seems to take care of the issue :) 19:31
dogbert17 nine++ 19:34
19:35 Xliff_ joined 19:36 Geth left, Geth joined
Xliff_ nine: So.... you solved the issue .... right when I joined? 19:39
nine Xliff_: sorry :P
Xliff_ nine: Like I care. But really, how does my work around fix the issue? 19:40
Mind youp this code -used to work-
So I'm a bit conf00sled.
nine That's rather normal for memory corruption issues
.oO( "Like I care" == "You have nothing to apologize for" )
So just a slight rearrangement of the internals can expose such bugs?
nine Or even just slightly different usage patterns 19:55
Geth MoarVM/fix_mixin_repossession: f7e0d7d358 | (Stefan Seifert)++ | src/6model/reprs/P6opaque.c
Fix memory corruption caused by repossessed mixins losing their replaced body

When a mixin got repossessed during deserialization, the replaced body pointer would get NULLed. If the mixin needed more storage than the original type provided we could then end up overwriting adjacent objects when deserializing the mixin's attributes.
... (5 more lines)
MoarVM: niner++ created pull request #1564:
Fix memory corruption caused by repossessed mixins losing their repla…
21:12 linkable6 left, evalable6 left 21:14 evalable6 joined 21:15 linkable6 joined 23:39 linkable6 left