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.
nine I've let it run all night and neither MVM_SPESH_BLOCKING=1 nor MVM_SPESH_DISABLE=1 nor gdb failed 06:59
dogbert17 nine: what conclusions do you draw from that result? 07:48
nine None. Except that the bug is somewhat elusive. This is quite typical for bugs that depend on precise timing or memory layout to reveal themselves. Like errors you get when run in make test but not when running a test file individually. 07:51
dogbert17 I tried turning off some spesh features. MVM_SPESH_PEA_DISABLE didn't fix the problem nor did MVM_SPESH_OSR_DISABLE. I couldn't get the problem to occur when MVM_SPESH_INLINE_DISABLE was set but perhaps it just takes longer. 07:52
nine Oh, wait a minute! It did actually fail in rr :)
I just forgot that I started the rr run in the shell where I previously run it without any additions (the one case where I could get it to fail) 07:53
nine Just took 1540 tries to fail in rr 07:53
dogbert17 that is fantastic 07:54
MasterDuke nice
nine And the bug may even be quite straight forward 07:57
We deserialize the method cache at github.com/MoarVM/MoarVM/blob/mast...on.c#L3171 07:58
Then run the work_loop to deserialize its entries. This may trigger GC. Since the cache at that point is not referenced by any root, we free it.
Serialization and deserialization runs with allocation in gen2 enabled, so we don't have tons of MVM_ROOT in the (de-)serialization code. But that only protects against pointers getting moved. Not actually against stuff getting freed. 07:59
MasterDuke move that ASSIGN_REF to right after the deserialize?
nine Yep, that sounds about right 08:00
Except for b4cd2a6555 08:05
So maybe MVM_ROOT is the way to go
MasterDuke ha 08:07
nine git++ 08:09
jnthnwrthngtn moarning o/ 09:36
jnthnwrthngtn wonders how many days he is away from killing off that method cache... :) 09:37
lizmat
.oO( its days are numbered! )
 09:38
Nicholas hacking days, or calendar days? 09:50
jnthnwrthngtn Given I've not got that much consulting stuff on my plate in July, those might be somewhat similar for the next while :) 09:51
Nicholas woohoo! Party on. 09:56
nine Oh darn....apparently the MVMROOT did not fix the issue. After 2 hours of running the test in a loop I got the error again 10:01
jnthnwrthngtn: MVMROOTing something should keep it from getting collected, shouldn't it?
jnthnwrthngtn nine: Only during the time the MVMROOT is in dynamic scope 10:03
But otherwise, yes, it counts as a GC root
nine I.e. MVMROOT(tc, cache, { if (sr->working == 1) work_loop(tc, sr); }); when deep inside work_loop GC gets triggered 10:04
jnthnwrthngtn Yes, that should suffice 10:06
If it doesn't, there's something else going on
But also, I thought everything deserialized ended up in gen2 anyway 10:07
lizmat maybe the process itself creates objects in the nursery?
jnthnwrthngtn "the process"? 10:08
lizmat the deserialization process
like a loop variable?
jnthnwrthngtn It shouldn't, in so far as the "please allocate directly in gen2" flag shuld be set at all times when we're in the deserialization process
nine jnthnwrthngtn: gen2_default is definitely set. But getting into gen2 doesn't protect something from getting freed, does it? After all we may still do a full collection 10:09
jnthnwrthngtn nine: This is correct, yes.
But. hm 10:10
The trigger for a full collection is a full nursery
nine I can trigger the bug reliably by adding an MVM_gc_enter_from_allocator(tc); after cache = MVM_serialization_read_ref(tc, sr);
While if I enter gc inside the MVMROOT, nothing happens
jnthnwrthngtn So I guess this only happens when there's another thread working while this one is deserializing
nine I wonder if my fix is correct but it's just that we have a similar bug elsewhere 10:13
It did take 2 hours to trigger it again after all 10:14
jnthnwrthngtn Possible; the deserialization code has probably usually always been inovked as the only running thread 10:15
nine cache = MVM_serialization_read_ref(tc, sr); 10:24
And once you start looking. At this point in read_param_intern, ptype and its STable are not rooted: github.com/MoarVM/MoarVM/blob/mast...on.c#L2695 10:25
They are in gen2, but not referenced
And we even do a nursery allocation
Geth MoarVM/new-disp: c370aa1bc1 | (Jonathan Worthington)++ | src/disp/boot.c
Correct a comment
 10:48
MoarVM/new-disp: 35f3039b3f | (Jonathan Worthington)++ | src/disp/boot.c
Make boot-code-constant dispatcher handle C funcs

Which is just wiring it up to code that has since been written for other purposes.
MoarVM/new-disp: 938291229b | (Jonathan Worthington)++ | 5 files
Implement the boot-code dispatcher

Which is like boot-code-constant, except it does not imply that the object should be considered a constant. The latter would cause bother with invoking closures, since we'd fixate on a given closure clone.
MoarVM/new-disp: 95b7435c3c | (Jonathan Worthington)++ | src/disp/boot.c
Cats may be pure, but captures they are not

  MasterDuke++ for noticing		 10:56
lizmat
.oO( it haz cats? )
 11:11
jnthnwrthngtn meow 11:15
Time for lunch
Nicholas jnthnwrthngtn: you know about this? 12:28
./rakudo-m -Ilib t/spec/S06-signature/closure-parameters.rakudo.moar
...
moar: src/core/interp.c:129: MVM_disp_inline_cache_get: Assertion `slot < cache->num_entries' failed. 12:29
Aborted
jnthnwrthngtn Nicholas: You mentioned it before. I failed to repro it. 12:39
Nicholas Was it the same testcase? 12:57
that's a spectest. I think that the previous was nqp
jnthnwrthngtn I already fixed the NQP build valgrind barf 12:58
I'm pretty sure the order was this one (failed to repro), the NQP one (fixed), and this one again. The assertion fail and test name look familiar, anyway 12:59
Nicholas *at least* one of us is confused :-) 13:00
colabti.org/irclogger/irclogger_lo...-06-22#l83
FSA assertion panic in NQP. Seems to be only on one machine I have access to 13:01
valgrind error was NQP
the assertion failure is a spectest
oh wait, it's me 13:02
colabti.org/irclogger/irclogger_lo...2021-06-21
you're tracking this better than me 13:03
jnthnwrthngtn Ah, I had forgotten the FSA one, I'm not sure if I conclusively failed to repro that 13:07
Nicholas IIRC I only had it on that machine, so I thought it might be compiler dependant 13:24
MasterDuke just a plain checkout of new-disp+setting FSA_DEBUG doesn't repro it for me 13:37
but i did get some sort of crash in rakudo's t/04-nativecall/01-argless.t once, but i can't repro it 13:38
is it expected that a lot of spectests fail? 13:47
jnthnwrthngtn MasterDuke: Probably 14:20
MasterDuke: I've not run spectest in a while on that branch; it feels like a long shot that it'd be close to passing given things are half way between two dispatch systems 14:21
MasterDuke ok, won't mention the failing ones then 14:22
jnthnwrthngtn Segfaults are useful to know about as those absolutely shouldn't happen, but other failure modes aren't surprising. Certain things always end up in the new dispatcher, but then encounter things that aren't set up for it. 14:23
I think I've probably gone about as far as I can with "sort of keep things working but turn on new-disp with an env var"; any next step runs into too many discrepancies. 14:24
Upcoming commits will work towards switching every call and callmethod compiled on MoarVM to the new dispatch mechanism. 14:25
And then getting NQP happy again. I expect during that time even the Rakudo build will be busted.
I can't really go any further with Rakudo because the next step is to compile the setting with new-disp used for multi dispatch 14:26
Well, and everything really
But that immediately runs into the problem that trying to call trait modifiers from the compiler blows up, because NQP calls aren't using new-disp 14:27
With that road having run out under me, there's not much for it than going for switching NQP over.
[Coke] Makes sense to me, FWIW - Will others be able to chip in to help, or will that make it harder? 14:31
(or, I suppose I mean, will others not be able to help because you'll be fixing the one next broken thing each time?)
jnthnwrthngtn [Coke]: I think once we're at the point where the big switchover is done and we're hunting regressed spectests, yes 15:02
Yay, got lang-call working 15:15
(dispatcher that will delegate to the appropriate HLL dispatcher)
Nicholas you have the beer fridge ready for later? 15:16
jnthnwrthngtn Yes
Nicholas Good. (Just checking)
jnthnwrthngtn Going to try and get lang-meth-call working before language class, though :)
Well, almost got it... 15:49
bbl
jnthnwrthngtn Seems Geth is giving my push the silent treatment, but the lang-call and lang-meth-call are in :) 17:22
The next step will be to change the QAST compiler to emit dispatch ops using them for `call` and `callmethod` nodes. 17:23
And then fix the world that results :)
Nicholas useless bot
jnthnwrthngtn Anyway, all that sounds too much effort for a sunny evening when there's beer in the fridge. :) 17:28
Oh! I also have mead... 17:29
Nicholas #firstworldproblems
have fun - it's still a bit too hot and humid outside here for me to find it enjoyable to sit outside 17:30
jnthnwrthngtn I'm about to test how it is here. I think it is hot and humid but there seems to be a breeze that will make it tolerable... 17:31
leont @jnthnwrthngtn: didn't know you were also a mead drinker 🙂 17:35
Nicholas I realse. I think I last drank mead before I learned perl. 18:17
MasterDuke i always thought i would like mead, and want to, but never really have 18:52
but there is a bigger cider selection here than in the us, so i've been trying lots of different ciders 18:53
jnthnwrthngtn leont: I wasn't until relatively recently, when I ordered a bunch of beer, the shop were out of one, and by cunning or incompetence substituted it with another product of the same brewery...which happened to be a mead. 22:15
Instead of complaining, I drank it, found it pleasant enough, and ordered some more the next time. I've nowhere near enough experience to know if what I'm drinking counts as a good mead. :) 22:16
www.eshop-axiombrewery.cz/axiom-br...sion-mead/ fwiw 22:17
Also: wow, this brewery have their own eshop now, that's new.
Now I don't have to figure who has their stuff in stock this time. 22:18
leont has about 15 liters of homebrew mead in his cellar (a)
jnthnwrthngtn Oh wow :)
leont My stuff is a bit stronger than that though, more comparable to wine than beer. Probably quite a different drink. 22:26
jnthnwrthngtn Yeah, sounds like. This one is on the sweet side, but pleasant in the summer. 22:33
japhb Mead always seemed to be more desert than general drink 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!