|
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 | |
| s/story/storage/ | |||
| 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 | ||
| Xliff_ | .oO( "Like I care" == "You have nothing to apologize for" ) |
19:41 | |
| nine++ | |||
| 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) |
20:06 | |
| 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
|
|||