|
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. |
|||
|
02:20
MasterDuke joined
|
|||
| MasterDuke | lizmat: i wondered if just disabling the jit on intel (actually amd for me) would trigger the crash (if there's a problem in spesh, but the jit is masking it), but it seems fine here | 02:22 | |
|
02:32
MasterDuke left
04:41
vrurg left
|
|||
| lizmat | yeah, disabling the JIT doesn't make it crash on the Intel for me either | 09:37 | |
| however, does disabling the JIT create the same codepath? Or does the M1 create a different codepath altogether because the jit is disabled at compile time of the VM ? | 09:39 | ||
|
10:37
sena_kun joined
13:44
epony left
14:19
vrurg joined
15:34
vrurg_ joined
15:36
vrurg left
15:37
vrurg_ is now known as vrurg
15:53
MasterDuke joined
|
|||
| MasterDuke | i built MoarVM with `--no-jit` (which i've never used before, so no idea how different it is from just MVM_JIT_DISABLE=1 at runtime), but still no crashes in that example | 15:54 | |
| ugexe | it never crashes for me on a m2 | 16:01 | |
| it isn't crashing for me on a m1 either | 16:02 | ||
| lizmat | weird my M1 is still on Monterey... I guess I'll up it to Sonoma... | 16:18 | |
| see whether that makes a change | 16:19 | ||
| ugexe | fwiw i just noticed the m1 is using an x86 rakudo executable | ||
| the m2 is using arm64 though | |||
| lizmat | hmmm | ||
| vrurg | My moar started crashing too on M2. On a totally fresh re-install of Rakudo. | 16:32 | |
| ugexe | as another data point i'm on the latest OS version 14.2 (23C64) | 16:33 | |
| lizmat | 12.7.2 for me will upgrade later today | 16:34 | |
| vrurg | Mine is 14.1.1, but I barely expect this to be a problem. | ||
| ugexe | file $(which rakudo) | 16:35 | |
| does that also show arm64 for ya'll? | 16:36 | ||
| lizmat | Mach-O 64-bit executable arm64 | 16:37 | |
| vrurg | The same here. | ||
| ugexe | i wonder why i can't reproduce on an m2 | 16:38 | |
| vrurg | Mine crashes in serialization, something related to repossession where it gets a NULL pointer from REPR structure. | ||
| ugexe | ok i got it when i changed .race to .race(:batch<1>) | 16:39 | |
|
16:49
epony joined
|
|||
| MasterDuke | after how long? i'm trying .race(:1batch) with --no-jit, but wow is it a lot slower | 16:50 | |
| lizmat | you're adding a *lot* of overhead to what is essentially just an nqp::op | 16:52 | |
| vrurg | My case is likely something different. Fresh HEAD, no traces of previous installs. Install zef, install App::Prove6. Then `prove6 -I. t` anywhere and it crashes with zeroified fields in REPR structure. | 16:53 | |
| MasterDuke | yeah, i'm just wondering how long i should let it go before considering it non-crashing | 16:55 | |
| well, it hadn't crashed after 16min, and i ran a spectest in the background. it hasn't finished yet, but i'm going to call that not reproducing the crash | 17:04 | ||
| lizmat | yeah, it was mere seconds for me | 17:06 | |
| ugexe | It occurs for me in under two minutes at least | 17:22 | |
| with batch 1 | |||
| vrurg | MasterDuke: out of curiosity, can you try my scenario? 100% reliability, immediate crash to me. | 17:23 | |
| vrurg is afk | 17:24 | ||
|
19:12
epony left
19:14
epony joined
|
|||
| MasterDuke | vrurg: well, `prove6 -I. t` doesn't crash using my normal rakudo install | 19:33 | |
| doesn't seem to either with a clean install (caveat emptor though, i believe i got all the parts (e.g., zef, prove6) using the new+clean install, but not 100% convinced) | 19:44 | ||
| vrurg | MasterDuke: are you on the latest HEAD? | 20:16 | |
|
22:30
MasterDuke left
23:18
sena_kun left
|
|||