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:05 reportable6 joined 00:41 patrickb left 00:42 patrickb joined 01:07 linkable6 joined 02:08 patrickb left 04:07 evalable6 left, linkable6 left, evalable6 joined 05:07 evalable6 left 05:09 evalable6 joined 05:10 squashable6 left 06:03 reportable6 left 06:05 reportable6 joined 06:09 linkable6 joined 07:51 Colt left 08:12 squashable6 joined 08:14 Colt joined 11:19 patrickb joined 12:02 reportable6 left 12:05 reportable6 joined
MasterDuke well, now all tests pass with MVM_VECTOR_* macros using the fsa, as long as i set MVM_JIT_EXPR_DISABLE=1 12:09
but i get an insta-`Unhandled exception: Cannot find method 'say' on object of type NQPFileHandle` in the nqp build without that 12:10
github.com/MoarVM/MoarVM/blob/mast...#L248-L253 isn't correct, right? 13:27
because if FSA_SIZE_DEBUG is enabled, MVM_fixed_size_alloc returns the address of the `memory` field inside the MVMFixedSizeAllocDebug (up at line 196), not the address of the entire struct 13:30
and then MVM_fixed_size_realloc_at_safepoint returns the MVMFixedSizeAllocDebug instead of the address of the `memory` field 13:31
shouldn't it be this? gist.github.com/MasterDuke17/6065d...820f16249f 13:32
13:50 RakuIRCLogger left, lizmat_ joined, Geth left, TempIRCLogger left 13:51 lizmat left
nine MasterDuke: no, it's not as much wrong as it is confusing. That line should read void *new_p = MVM_fixed_size_alloc(tc, al, new_bytes); 14:23
Since the wrongly typed pointer is never dereferenced, it doesn't matter that much. A pointer is a pointer after all. But it's clearly misleading the reader 14:25
MasterDuke ah, true
hm. even though everything runs fine with MVM_JIT_EXPR_DISABLE=1, if i turn on FSA_SIZE_DEBUG i get an invalid free in MVM_fixed_size_realloc. well, maybe if i fix whatever is going on it'll also fix the expr jit... 14:31
nine Geth down? 16:28
github.com/MoarVM/MoarVM/commit/bd...6b168f6a47 Properly extend int return values of native calls to 64 bits 16:31
Native functions leave it to their caller to extend values with a size of less than a full register width (as the caller may alternatively simply access only the relevant part of the register). So we need to do that as well before we write the full register back into the VM register. The old native call JIT did this right already, so lets just salvage the code.
This takes care of the Cro::TLS test failures 16:32
lizmat_: can you please test Ecosystem::Archive with this fix applied?
16:50 evalable6 left, linkable6 left 16:52 linkable6 joined 17:48 lizmat_ left, lizmat joined, TempIRCLogger joined 17:49 Geth joined
lizmat nine: Geth is up again, sadly I don't have rights to re-send webhooks 17:50
18:02 reportable6 left
nine lizmat: please say that my commit fixed Ecosystem::Archive :) 18:11
lizmat building 18:12
nine: good news, indeed it does 18:27
shall I bump MoarVM accordingly ?
dogbert17 lizmat: go for it :) there's already another fix there waiting for a bump 18:31
lizmat oki
let's see if I can do this without screwing up -)
dogbert17 I suspect the bump will be a success 18:32
nine I have full confidence :) 18:37
The sad part is that I actually suspected exactly this kind of issue 2 days ago. But the reduced test cases I tried ran all correctly 18:38
dogbert17 nine++, another bug squashed 18:39
soon ther won't be any bugs left :)
*there
nine I've had a look at a t/spec/S32-num/complex.t (Issue #1607) but I just cannot reproduce it locally 18:44
dogbert17 oh no
MasterDuke had better luck
nine Oh, I just noticed that you were using a nursery of 52 not 50. Maybe that's it 18:45
MoarVM panic: Invalid owner in item added to GC worklist
dogbert17 yay 18:46
some bugs doesn't seem to get triggered if the nursery size is too low, e.g. 8k 18:49
nine Yes, they also don't get triggered with MVM_GC_DEBUG=3. That's why I have a local patch that extends an object's stay in the nursery to 15 GC rounds. But....you don't know what "slow" means until you tried that. 18:50
dogbert17 would it be possible to somehow protect the memory making up (fromspace ?) so that if someone tries to access something there the program goes kaboom? 18:52
using something like mprotect 18:53
lizmat so, after this, OO::Monitors is acting up again 18:55
dogbert17 ah, your nemesis module :)
lizmat so I nuke ~/.raku/precomp
no change
so I uninstall OO::Monitors and try to install it again
===> Testing: OO::Monitors:ver<1.1.1> 18:56
[OO::Monitors] ===SORRY!=== Error while compiling /Users/liz/.zef/store/OO-Monitors/8595BE0FFBD285610133E9324014AC5D91660646/t/BUILD.t
[OO::Monitors] Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from '/Users/liz/.zef/store/OO-Monitors/8595BE0FFBD285610133E9324014AC5D91660646/lib/OO/Monitors.pm6 (OO::Monitors)')
WAT ?
so I nuke ~/.zef/store/OO-Monitors 18:57
and then install of OO::Monitors works 18:58
dogbert17 strange 18:59
nine dogbert17: I think I actually did that mprotect thing once 19:03
dogbert17 cool 19:04
but I guess that there was a gotcha of some kind ?
nine dogbert17: look at the gc_torture branch
19:05 reportable6 joined
dogbert17 nine: will do 19:05
lizmat: I can confirm your problem, had oo-monitors cloned on my machine and got the same error when running its tests 19:07
lizmat so I figure that ~/.zef/store/OO-Monitors actually had a precomp in there 19:09
next time I will check before nuking 19:10
dogbert17 for me wiping the .precomp dir in the oo-monitors lib directory fixed the problem
lizmat dogbert17: in the zef store ? 19:11
ah, you had a local checkout of it 19:12
dogbert17 yes, a local checkout, I use it for testing a few modules that have been causing trouble in the past 19:14
19:20 TempIRCLogger left, TempIRCLogger joined
MasterDuke oh, this is interesting. so with FSA_SIZE_DEBUG enabled, MVM_fixed_size_realloc grabs a pointer 8 before the one you pass in github.com/MoarVM/MoarVM/blob/mast...loc.c#L225 20:26
however, this requires the passed in pointer to have originally been alloced by MVM_fixed_size_alloc*
whereas regular realloc can accept the NULL pointer, in which case it just acts like malloc 20:27
and the MVM_VECTOR_* macros can initialize things to NULL, and then call realloc on them, expecting it to act like malloc in that case. so converting them to use the fsa blows up FSA_SIZE_DEBUG 20:29
i guess i can just add an `if (p) { <existing path> } else { MVM_fixed_size_alloc() }` in the `#if FSA_SIZE_DEBUG` branch of MVM_fixed_size_realloc... 20:30
20:49 squashable6 left
nine sounds sensible 21:49
MasterDuke yeah, that seemed to work. but, i now get a `free(): invalid pointer` in MVM_gc_worklist_destroy... 22:08
so far this has been relatively straightforward. but before i start another more-involved-than-i-expected/hoped project, i guess i should see if people are going to be in favor of the outcome 22:09
i've been doing this on top of github.com/MoarVM/MoarVM/pull/1608, though the changes aren't actually dependent on it 22:10
so maybe i should ask if i do end up with another commit for that PR (or a separate PR), that does correctly convert the MVM_VECTOR_* macros to use the fsa, is that something likely to be merged? 22:12
22:16 linkable6 left 22:17 linkable6 joined 22:51 squashable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!