|
00:24
shareable6__ joined
00:25
shareable6 left
01:53
guifa joined
03:43
guifa left
07:20
ShimmerFairy left,
ShimmerFairy joined
13:11
apogee_ntv left
13:13
apogee_ntv joined
|
|||
| apogee_ntv | github.com/MoarVM/MoarVM/issues/2058 This was fun. | 16:41 | |
| lizmat | apogee_ntv++ | 16:43 | |
| apogee_ntv | I am writing another, this app seems like the perfect VM stress test :D | 16:49 | |
| I found the bug I am now writing while trying to reproduce that one. | 16:50 | ||
| lizmat | cool! | ||
| apogee_ntv | Yeah just trying to find the best reproducer (this is where AI helps, if you can find the shape of the bug it's usually good at iterating on code until you get something reliable) | 16:51 | |
| github.com/MoarVM/MoarVM/issues/2059 | 17:15 | ||
| lizmat | both cofirmed here | 17:22 | |
| apogee_ntv | I can try to look into fixing later if I'm less tired :D just spent 6hrs tabbing between lldb and a program that didn't want to crash haha | 17:25 | |
| And gave me a different crash when I tried to investigate the first one | |||
| lizmat | yeah, debugging these can be hell... thanks for taking one for the team! | 17:26 | |
| apogee_ntv | Haha it did the usual thing of once I'd managed to nail one down, every crash was that one instead of the other one. | 17:27 | |
| I only knew it was a different crash because one printed a MoarVM panic and the other just did a bare segfault. | 17:28 | ||
| Geth | MoarVM: m-doughty++ created pull request #2060: #2059 - On a full collection, sweep existing thread's gen2 before transferring it |
18:18 | |
| linkable6 | MOARVM#2059 [open]: github.com/MoarVM/MoarVM/issues/2059 Use-After-Free: UAF when a thread's final GC run is a full collection (its gen2 is transferred with stale `MVM_CF_GEN2_LIVE` marks) | ||
| apogee_ntv | OK now I will actually rest and try to fix the other one later. I ran nqp tests and everything was clean there. | 18:20 | |
| Not 100% sure how MoarVM is usually tested. | |||
| [Coke] | there is CI that runs it against nqp | 19:19 | |
| (and rakudo, I think) | |||
| and we do occasional blin runs. | |||
| e.g. here's a passing moarvm CI run from a recent PR: dev.azure.com/MoarVM/MoarVM/_build...041f6b71c8 | 19:45 | ||
| builds and tests moarvm, nqp, rakudo on various OSes with various settings | |||
| apogee_ntv | Thanks, yeah I need to set up something locally if I'm going to contribute more often. | 20:56 | |
| Looks like that PR failed on something timing out | 22:12 | ||
| Geth | MoarVM: m-doughty++ created pull request #2061: #2058 - Object's owner now always matches the thread whose gen2 holds it |
22:45 | |
| linkable6 | MOARVM#2058 [open]: github.com/MoarVM/MoarVM/issues/2058 Cross-Thread Panic: Cross-thread nqp::objectid on another thread's young object leaves stale GC ownership after allocating thread exits | ||
| apogee_ntv | github.com/MoarVM/MoarVM/pull/2061 Less confident that this one is right. It does fix the bug but the semantic meaning of the `owner` in the object header seems to be two different things. Maybe I'm misunderstanding it but this should be a good starting point. | 22:46 | |
|
23:33
guifa joined
|
|||