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:03 reportable6 left, reportable6 joined 00:11 frost joined 02:15 frost left 02:16 MasterDuke left 03:10 AlexDaniel left 03:12 AlexDaniel joined 03:35 AlexDaniel left 05:22 coverable6 left, greppable6 left, notable6 left, statisfiable6 left, benchable6 left, shareable6 left, bisectable6 left, unicodable6 left, quotable6 left, committable6 left, bloatable6 left, linkable6 left, releasable6 left, reportable6 left, evalable6 left, nativecallable6 left, sourceable6 left, tellable6 left, squashable6 left, sourceable6 joined, releasable6 joined, notable6 joined, benchable6 joined, quotable6 joined, squashable6 joined, linkable6 joined, committable6 joined 05:23 unicodable6 joined, reportable6 joined, coverable6 joined 05:24 tellable6 joined, statisfiable6 joined, bloatable6 joined, nativecallable6 joined 05:25 evalable6 joined, shareable6 joined, greppable6 joined, bisectable6 joined 05:26 squashable6 left 05:28 squashable6 joined
nine So those were legit? Cool :) 05:57
06:02 reportable6 left 06:03 reportable6 joined
nine jnthnwrthngtn: is the lack of break; for case MVMDispOpcodeGuardNoResumptionCaller and MVMDispOpcodeUpdateResumeState in MVM_disp_program_run intentional? 06:17
07:05 patrickb joined 07:25 AlexDaniel joined 07:49 AlexDaniel left 08:00 AlexDaniel joined 08:23 AlexDaniel left 08:33 AlexDaniel joined 08:40 AlexDaniel left 09:00 frost joined 09:06 AlexDaniel joined 10:09 linkable6 left, evalable6 left 10:11 evalable6 joined, linkable6 joined 10:22 Kaiepi left 10:23 Kaiepi joined
jnthnwrthngtn nine: Well, some of them were skating on thin ice: they invoked a relatively complex process that - if it gives a certain return value - should not have resulted in any allocations taking place. However, static analysis can't reasonably know that property, and there's a relatively high risk of a future change resulting in allocations happening, at which point we'd risk breakage. 10:26
So I decided on balance it's better to add them. Anything that gets really hot will end up with the dispatch program compiled into ops anyway.
And parts of it spesh'd away
And won't hit this. 10:27
10:42 discord-raku-bot left 10:56 discord-raku-bot joined 12:02 reportable6 left 12:03 reportable6 joined
jnthnwrthngtn Time for round 3 of trying to figure out the bug, except I've also found a new way to make ASAN go boom early in the build 12:27
nine: Hm, that looks suspect; will look at it, though later (nothing in NQP uses resumption) 12:31
Ah, turns out the reason I didn't see the ASAN blow-up before isn't because it's new, but because it only happens when MVM_SPESH_DISABLE=1 is set. So the opposite direction to the effect that flag normally causes... 12:38
13:03 linkable6 left, evalable6 left 13:06 linkable6 joined, evalable6 joined
jnthnwrthngtn nine, sena_kun Even after I install the kernel module and install a newer rr (--version says 5.4.0) it still doesn't work for me; the error has changed to "[FATAL /build/rr-D6ACZo/rr-5.4.0/src/PerfCounters_x86.h:94:compute_cpu_microarch()] AMD CPU type 0x20f10 unknown" 13:06
Did you do a bleeding edge source install or some such?
github.com/rr-debugger/rr/commit/9...67e9930ece seems to be the commit I need 13:07
ah, yes, the release was before then 13:08
sena_kun jnthnwrthngtn, did you apply the patch from the wiki page?
jnthnwrthngtn sena_kun: The kernel module? 13:09
Yes
But for rr itself I just installed the latest package, which it seems is too old. I guess I need to do a source build
sena_kun :/
jnthnwrthngtn Did you get it working on your newest machine, btw? (Pretty sure it's the same CPU as I have.)
sena_kun perhaps, would be great if it works
for the record I did not try it, as I don't debug C usually. 13:10
so not so much info, sorry
jnthnwrthngtn Seems a source build works. Now i need to figure out hwo to use it :) 13:17
nine jnthnwrthngtn: yes, running it on a 5950X 13:18
jnthnwrthngtn: rr record whatever-you-want-to-record ; rr replay 13:19
then you're in gdb and have now the power of reverse-continue, reverse-next and reverse-step :)
13:19 frost left
nine What I mostly do is watch -l foo->bar[1]->borked and reverse-continue 13:20
jnthnwrthngtn Ah, I thought it wasn't working, but didn't realize it puts me at the start of execution and I needed to `continue` to get to the segv of interest :) 13:23
Brilliant. I thought this one should be good with rr, and indeed, it points right at the problem 13:29
Geth MoarVM/new-disp: d2d2628aa2 | (Jonathan Worthington)++ | src/6model/reprs/MVMCFunction.c
Clear cur_args_callsite when adapting legacy args

Otherwise we will try to GC mark the args buffer according to the legacy layout.		 13:34
jnthnwrthngtn nine++ sena_kun++ for rr help 13:35
Geth MoarVM/new-disp: 54bdf4595d | (Jonathan Worthington)++ | src/6model/reprs/MVMCFunction.c
Clear cur_args_callsite when adapting legacy args

Otherwise we will try to GC mark the args buffer according to the legacy layout.		 13:48
jnthnwrthngtn Hmm, using rr record on the NQP runner seems not to work out? 13:51
(can't continue past the execve) 13:57
patrickb jnthn: The runner generated in the build dir uses execve, while the installed one doesn't. You could just debug the installed executable 14:05
tellable6 patrickb, I'll pass your message to jnthn
patrickb jnthnwrthngtn: ^ 14:11
jnthnwrthngtn patrickb: Ah, interesting, thanks. There's also a workaround with rr too that I ended up using 14:22
nine what's the workaround? 14:28
jnthnwrthngtn Use `when` to get teh current event number, then `rr reply -g X` where X is the value when gives you plus something big enough to get over the execve (unless you're looking for something super early in MoarVM execution, -g 2000 is plenty enough) 14:30
ops, *replay
Unless the amount of work the runner does changes, you can just throw on the -g 2000 argument, I think
The first step (run it until it hits the execve and using when) is just to get a reasonable guess at the number 14:32
Sadly, the reverse debugger doesn't tell me much more about the bug I was hunting; it confirms a GC run scribbles over the arg name MVMString object, which fits what I already knew 14:34
Argh, I found it :/ 14:37
That was silly
Geth MoarVM/new-disp: 7a8c13942a | (Jonathan Worthington)++ | src/core/callsite.c
Make sure to mark and cleanup all interns

The `max_arity` is an inclusive endpoint, not an exclusive one.		 14:38
jnthnwrthngtn I nabbed the code from the interns cleanup, which already had the off-by-one, and didn't notice 14:39
With the explosive build fixed, it's back to the explosive tests. 14:47
Nicholas ASAN is excited by t/nqp/053-knowhow.t and t/nqp/090-findmethod.t 15:03
jnthnwrthngtn Yes, those are the very ones I'm looking at. It's bizzare. 15:33
It seems we somehow try to return from the same frame twice... 16:02
16:18 linkable6 left, evalable6 joined, evalable6 left 16:19 evalable6 joined, linkable6 joined
jnthnwrthngtn Ah, which in turn is 'cus there's a stray flattening call stack record 16:28
Geth MoarVM/new-disp: 4a26415193 | (Jonathan Worthington)++ | src/core/callstack.c
Don't leave flattening records behind

Otherwise, we'll be expecting bytecode frame records, won't find them, and will end up not leaving a bytecode frame when we expect to do so. Fixes the ASAN excitement in a couple of NQP tests.		 17:01
jnthnwrthngtn Now there's only one failing NQP test file for something that I've yet to decide should survive anyway 17:02
GC stressing shows up a few more failures in tests that don't show up in the build, curiously 17:04
timo an exciting read, the backlog for today and yesterday 17:09
Nicholas curious, yes. 17:34
For me, ASAN is bored again. t/nqp/097-hll.t fails 39, 40, 41, 42 then aborts with lang-meth-call cannot work out how to dispatch on type '(null)'
but I assume that you know that.
timo who putted a null in there 17:40
Nicholas given the 4 preceding test failures, I suspect that it's just confused. 17:41
timo foncused 17:43
jnthnwrthngtn Reuse code they said. There'll be less bugs they said. 17:47
Nicholas They were wrong. There would be fewer :-) 17:48
Nicholas ducks
Geth MoarVM/new-disp: 0eab228b36 | (Jonathan Worthington)++ | 3 files
Distinguish cases of dispatch run record unwinding

When we are unwinding it becaues of a success, we want to remove any flattening record that lies underneath it, because the invocation is completed. This was fixed in the previous commit. Unfortunately, this code was also used when we want to drop a dispatch run record because we didn't meet the guards - in which case we're going to try another dispatch program or record a new one, and in this case we certainly do not want to throw away the args flattening frame, because we need the flattened args for the next thing we try, and the eventual dispatch target.		 17:51
jnthnwrthngtn Well, arguably this was half a bug in that it was right in half the cases :) 17:53
Anyway, yay, now NQP builds and passes tests with the FSA debug and small nursery and GC debug checks
And yes, the NQP test that fails is the one where I'm pondering whether to toss out the mechanism in question entirely
It can stay failing until I make my mind up :) 17:54
Nicholas how full is your beer fridge? Does that test need to worry?
jnthnwrthngtn The beer fridge is very full due to a restock earlier this week. It was a challenge to fit it all in, especially keeping it sorted by type of beer.
The NQP test that fails is lower priority than doing the Rakudo build fixing at this point, I think 17:55
And with GC stressing that now says segfault 17:56
Nicholas That sounds like the right trade off, as I can assume that you know what the implications of that test (failing) means
jnthnwrthngtn Yeah, I need to decide what to do about method calls where we don't find the method 17:58
And it's not quite so simple as "the Raku dispatch throws the Raku error" because then we get inter-lang calls wrong
Without the GC stressing and stuff Raku's build now reaches the point I expected it to break.
+++ Compiling blib/Perl6/BOOTSTRAP/v6c.moarvm 17:59
lang-meth-call cannot work out how to dispatch on type 'Attribute'
.oO( This is not the greatest bug in the world...this is just Attribute... )
Nicholas oh noes 18:00
jnthnwrthngtn That happens because in the bootstrap we didn't yet set up the dispatchers, so it's a timing/ordering problem, though maybe solvable by temporarily using the NQP dispatcher in place of the Rakudo one, because it knows enough
I'll try it, but right now I want a) dinner, b) to make the beer fridge less crowded 18:01
18:02 reportable6 left 18:05 reportable6 joined
timo i'm sorry, nqp dispatcher, but you know to much ... *blam* 18:08
20:24 [Coke] left, [Coke] joined
nine The word attribute will never be the same 20:28
Though...I like the song and the video, so it's ok :) 20:29
japhb OK, now I'm wondering what video you're talking about, and whether I'd already heard the song and forgotten it or never heard it. 21:11
21:39 patrickb left 23:43 cognominal left

Powered by Cro and the Raku® Programming Language.

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

Thank you!