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 01:28 notable6 left, evalable6 left, greppable6 left, squashable6 left, committable6 left, quotable6 left, bisectable6 left, releasable6 left, coverable6 left, shareable6 left, bloatable6 left, reportable6 left, tellable6 left, sourceable6 left, benchable6 left, nativecallable6 left, unicodable6 left, statisfiable6 left, squashable6 joined 01:29 sourceable6 joined, releasable6 joined, evalable6 joined 01:30 bisectable6 joined, notable6 joined, unicodable6 joined 01:31 benchable6 joined 02:30 reportable6 joined, quotable6 joined, nativecallable6 joined, shareable6 joined, coverable6 joined, greppable6 joined
[Coke] moon-child suggested a workaround, build progressing... 02:57
gist.github.com/coke/8bffe7f4823e2...cf07f7d782 03:03
patch there lets all the obj files builf then get err3.out on src\jit\x64\emit.dasc 03:04
03:05 linkable6 joined 04:27 releasable6 left, coverable6 left, quotable6 left, reportable6 left, notable6 left, shareable6 left, sourceable6 left, evalable6 left, greppable6 left, nativecallable6 left, linkable6 left, bisectable6 left, squashable6 left, benchable6 left, unicodable6 left, quotable6 joined 04:28 unicodable6 joined 04:29 tellable6 joined, coverable6 joined, committable6 joined, nativecallable6 joined, linkable6 joined, sourceable6 joined, notable6 joined 04:30 reportable6 joined, shareable6 joined 05:27 releasable6 joined 05:28 greppable6 joined 05:29 statisfiable6 joined 05:30 bisectable6 joined, benchable6 joined
nine [Coke]: this should take care of that JIT build issue: gist.github.com/niner/47eef9bdd295...bf32c2dc0d 06:01
06:02 reportable6 left 06:04 reportable6 joined 06:28 evalable6 joined 07:28 squashable6 joined
dogbert17 nine: the SEGV I saw when running 'while ./rakudo-m -Ilib t/spec/S07-hyperrace/for.t; do :; done' has decided to go into hiding, at least on my machine 09:20
the SEGV, or perhaps it's another one, does make a comeback if I add MVM_SPESH_BLOCKING=1 09:23
nine: perhaps you or timos cats :) have a theory as to what's going on 09:28
gist.github.com/dogbert17/6cafae9e...c063708d63
09:30 bloatable6 joined
jnthnwrthngtn moarning o/ 09:52
dogbert17 good morning jnthnwrthngtn, have you had any coffee yet? 09:54
Nicholas \o 09:55
dogbert17 good morning Nicholas 09:56
Nicholas MasterDuke: busy elsewhere - can't look yet. It's possible.
jnthnwrthngtn Yes, although I realized after pressing the button to make it that the water tank was very low
However on the office machine in-flight refueling is possible :)
dogbert17 nice
Nicholas I realise that I must confess to a coffee bootstrapping near-miss this mornign, but I salvaged it with a tea infuser. 09:57
10:03 lizmat left
nine dogbert17: I've gotten the same segfault in rr. code->sf is NULL, isn't it? 10:26
That's the GC issue I mentioned
dogbert17 nine: yes code->sf is NULL
nine jnthnwrthngtn: the segfault in S07-hyperrace/for.t is due to *code being all 0s as it's been garbage collected while still in use. *code is part of invoke_args in github.com/MoarVM/MoarVM/blob/new-...am.c#L2829 and gets added by MVMDispOpcodeSet in github.com/MoarVM/MoarVM/blob/new-...am.c#L2738 10:31
Any hand waving (or straight fixes) appreciated :)
Just a random observation: fixing the hardest category of bugs is certainly a way to learn about a major new subsystem. I can't shake the feeling though that it's not actually the easiest way to learn... 10:33
jnthnwrthngtn nine: At 2829 there isn't code, there's wrapper 10:42
I assume that's what you mean?
10:43 sena_kun joined
nine Ah, sorry, calling wrapper ends up in try_capture_lex_impl where we get code from MVMObject *code = MVM_args_get_required_pos_obj(tc, &arg_ctx, 0); 10:44
Geth MoarVM/new-disp: 5802f28245 | (Jonathan Worthington)++ | src/disp/program.c
Set chosen dispatch program before spesh logging

Otherwise, if the spesh logging allocates, the information that the GC needs in order to mark dispatch program temporaries will not be available, and so they won't be marked.		 10:45
jnthnwrthngtn See if that helps
Wonder if I p'd instead of P'd :)
10:50 lizmat joined
jnthnwrthngtn I wonder if I shoulda got rid of p6bindassert in favor of a `dispatch`, so we didn't need another special case op 10:52
As in, another one to handle in spesh specially
The thing is that it's not quite powerful enough
I need some way to signifity "overall bind success" 10:53
*signify 10:54
And also a way to ask "Should I throw an error on bind failure or just indicate that it happened"
oops, I didn't mean p6bindassert, I meant assertparamcheck
sena_kun jnthnwrthngtn, do you want a blin run? 10:55
jnthnwrthngtn sena_kun: I don't think there'll be all that much change since the last one
sena_kun .oO ( maybe just a blin this time )
jnthnwrthngtn
.oO( it is lunch time... )
I'm pondering the best way to fix a bunch of the remaining spectest failures (the ones that depend on unpacking) 10:56
I need the positive outcome part for nextcallee with multiple dispatch
sena_kun Ah, related to the signature too many/few and such errors? Best of luck.
jnthnwrthngtn Yes 11:04
11:59 linkable6 left, evalable6 left, evalable6 joined
nine I wonder if this will also fix zef uninstall. I guess we'll see :) 12:02
12:03 reportable6 left 12:21 frost joined
Geth MoarVM: d4a8093ebc | (Stefan Seifert)++ | src/spesh/worker.c
Fix deadlock by untimely GC in multi-threaded programs

In send_log we're marking the thread blocked while holding the sl->body.block_mutex. In the spesh worker we're trying to lock the sl->body.block_mutex without the thread being marked blocked for GC. Now if some other thread at that point has decided that a GC run is in order, send_log will wait for the GC run. But the GC run cannot start until the spesh ... (5 more lines)		 12:24
MoarVM: 96ce6d8485 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/spesh/worker.c
Merge pull request #1526 from MoarVM/fix_spesh_log_gc_deadlock

Fix deadlock by untimely GC in multi-threaded programs
13:04 reportable6 joined
Geth MoarVM/new-disp: e4963d3b5b | (Jonathan Worthington)++ | src/disp/syscall.c
Add bind-will-resume-on-failure syscall

Provides introspection of whether a bind failure in the current routine will trigger a resumption. This will be used in Rakudo in order to make multiple dispatch based upon signature unpacking work again.
In Rakudo master, this is done by binding the signature twice: once to ... (11 more lines)		 13:08
jnthnwrthngtn m: say 1344 / 1349 13:11
camelia 0.996294
jnthnwrthngtn Only 5 failures in `make spectest` now
lizmat: 99.6% passing spectests, if you're looking for a number for the weekly :)
lizmat noted :-) 13:19
jnthnwrthngtn nine: Yes, zef is fixed
13:20 frost left
sena_kun yay 13:21
yay 13:22
13:36 frost joined 13:40 frost left
nine jnthnwrthngtn: can confirm :) 14:24
Geth MoarVM/new-disp: 8b9270918e | (Jonathan Worthington)++ | 6 files
Generalize bind failure to resumption mechanism

In preparation for being able to also have a bind success trigger an exit of the routine and a resumption. We'll use this for situations like nextcallee, where we only want to run signature binding and then leave the routine.		 14:25
14:40 evalable6 left 15:00 linkable6 joined
Nicholas jnthnwrthngtn: fixes my rakudo build fail 15:06
jnthnwrthngtn \o/ 15:21
m: use Test; multi def_unpack(@a) { @a.join(',') }; multi def_unpack([$x, $y, $z]) { my &nc = nextcallee; "nc:" ~ nc() }; say def_unpack([1,2,3]) 15:36
camelia Too few positionals passed; expected 1 argument but got 0
in sub def_unpack at <tmp> line 1
in sub def_unpack at <tmp> line 1
in block <unit> at <tmp> line 1
jnthnwrthngtn m: use Test; multi def_unpack(@a) { @a.join(',') }; multi def_unpack([$x, $y, $z]) { my &nc = nextcallee; "nc:" ~ nc([4,5,6]) }; say def_unpack([1,2,3]) 15:37
camelia nc:4,5,6
jnthnwrthngtn Turns out we lack tests for this situation
15:43 evalable6 joined
[Coke] nine: thanks. jit left wit hthese warnings: src\jit\x64\emit.c(8): warning C4129: 'j': unrecognized character escape sequence 15:49
src\jit\x64\emit.c(8): warning C4129: 'e': unrecognized character escape sequence
nine [Coke]: I guess that these warnings are not actually new 15:51
Line 8 is: line 1 "src/jit/x64/emit.dasc"
Actually, #line 1, so it's a pragma and I guess msvc is trying to interpret /x sequences in it 15:52
[Coke] build completed on windows, woot 15:54
baking up and doing a rakudo build now... 15:59
*backing
nine I'd be content with NQP building :D 16:05
[Coke] yah, dies immediately. :( 16:10
nine That's the point where we really need a debugger to get at the failure 16:11
[Coke] gist.github.com/coke/8bffe7f4823e2...-err-4-out 16:12
not sure that's a moarvm error, actually. 16:13
nine Error code 0xc0000005 means access violation, i.e. a segfault
[Coke] Not sure why the nmake call would have worked in moarvm but not nqp. 16:14
nine Which is what I'd expect from an error in the JIT implementation.
[Coke] ah. I saw "nmake\x{a}" which looked sus.
nine It's not nmake which fails. It's MoarVM.
[Coke] (yup, see that now, like I said, the extra text looked sus, that's all) 16:15
Will try with jit disabled. 16:16
got past the segfault 16:17
nine Any chance of attaching a debugger? 16:18
[Coke] I have visual studio, should be possible.
... I have to figure it out, though.
let me see how it does sans JIT and then I can get you that.
nqp passes make test 16:23
rakudo build dies with: 16:24
getcodeobj needs a code ref at gen\moar\Ops.nqp:392 (blib/Perl6/Ops.moarvm:) from gen\moar\stage2\QAST.nqp:1619 (C:\sandbox\rakudo-disp\install\share\nqp\lib/QAST.moarvm:compile_op)
nine That's a rather surprising failure mode 16:27
[Coke]: you sure you are on new-disp in all 3 repositories? 16:28
[Coke] ... dammit. 16:30
very good guess!
just blew away my nqp build to get debug info, wll retry shortly
got a stack trace! it wan't a debug build. :) 16:39
nine Seems like it's not exactly gonna be hard to reproduce those segfaults... 16:40
[Coke] :)
I will say that the build *feels* faster, but I don't build on windows frequently. 16:46
Geth MoarVM/new-disp: c072f53c2f | (Jonathan Worthington)++ | 13 files
Provide a way to always resume after binding

So that if we want to invoke something simply to see if it would bind, that is now possible. This will be used most immediately for handling nextcallee in multiple dispatch with unpacks or `where` clauses, but will have some further usages also.		 16:47
jnthnwrthngtn This could actually be a useful to expose, since things like Cro::HTTP::Router today do a signature bind check and then an invocation also 16:51
[Coke] nine: actually dying on log.c line 129. "exception thrown: read access violation: cs_args_flags was 0x111011101110112." 16:53
let me see if I can easily extract teh call stack 16:54
gist.github.com/coke/55ba508f67e8e...3e795a215b
please let me know if getting any values out will help. 16:55
(can't do a screen share to this box, unfortunately)
(did a simple c/p for both the values and the stack, the formatting ain't great in the paste) 16:57
looks like cs->flag_count is one, but cs->arg_flags is NULL 16:58
should that loop be over arg_count, not flag_count??
github.com/MoarVM/MoarVM/blob/c072...#L124-L131 17:01
getting the segfault on line 129 there.
nine flag_count is correct (yes, that's a bit confusing) 17:03
The arguments to MVM_frame_dispatch would be of interest. Including the values in the args struct
It's a bit odd, that there's no callframe for MVM_jit_code_enter, but line 6243 is in sp_jit_enter, so it's gonna be a JIT issue 17:05
[Coke] added file to the gist with that. let me know if you need me to drill down on anything 17:06
getting the point where a screen grab might be better...
nine Hey, I haven't even asked for a disassembly yet :D 17:09
[Coke] anticipating your request, I have found the "go to disassembly" menu option. :) 17:10
jnthnwrthngtn It's quite possible that the debugger is confused by the JIT frames and so "loses" the MVM_jit_code_enter call 17:11
nine I have to admit that I find the vars output rather confusing 17:16
Not because of the values, but structurally. 17:17
[Coke] let me try screen grab. 17:18
added 17:22
(there is a horiz. scroll there also)
17:25 sena_kun left
jnthnwrthngtn bbl & 17:26
18:02 reportable6 left
timo solderin' time 18:22
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/08/02/2021-...ting-down/ 18:37
nine Ah, ok. The most interesting to me are code, args and spesh_cand 18:39
[Coke] frame.args is all NULLs and 0s 18:59
nine Not frame.args, args
The argument to MVM_frame_dispatch itself 19:00
[Coke] frame.spesh_cand is NULL
nine These: moar.dll!MVM_frame_dispatch(MVMThreadContext * tc, MVMCode * code, MVMArgs args, int spesh_cand)
19:05 reportable6 joined
[Coke] (sorry, $DAYJOB, one sec) 19:25
the tc is a huge structure. 19:27
spesh_cand: optimized away and not availale
that's weird, one key is "paramet", next is "erized" 19:35
nine That's just jnthnwrthngtn having fun ;) 19:39
So what's in args? 19:40
[Coke] there's no easy way to say "expand all levels", so it's a lot of clicking and then multiple captures. one moment. 19:41
look at args*.png for args 19:46
Thank you for your patience and assistance. :) 19:47
looking for a plugin that helps export this stuff... 20:08
AHA. nine, check out the .cs files, same gist. 20:15
found an exporter that dumps it as an object initialization.
nine As I feared, args is totally bogus 20:19
[Coke] ... or I can get json (and I may have not gone full depth. one sec.) 20:21
nine Well, maybe not totally. args.source may be sane. Which would indicate that it's just the order that's wrong 20:22
[Coke] ok. need to see some other data? Hopefully my local changes to the struct initializers are correct. (was a lot of { }; those were changed to {0})
nine Can you please try this other patch as well? gist.github.com/niner/08f62474f3a2...cc6f8acfc6 20:24
[Coke] sure, testing... 20:29
I retract my "build seems faster" comment, though I'm now *watching it*, and on battery. :) 20:33
20:40 linkable6 left
[Coke] still dies. 20:40
20:40 linkable6 joined
[Coke] launching debugger... 20:40
stack trace looks similar 20:41
will redump args++
(doing the export is sloooow) 20:44
did the export, put them in the gist git repo... no change from previous variant 21:00
ah, thats a lie. one sec. 21:01
pushed. 21:02
nine Huh...it just seems to have exported to a deeper level. But the values are just as broken 21:09
in the same way even
My other hypothesis is that the values on the stack get overwritten by the callee 21:10
I'm not a 100% sure about the stack layout. That it's growing downwards doesn't exactly help 21:12
Maybe brrt++ can bring some clarity
Need to go to bed now
21:31 Altai-man left
timo if we can't use rr on windows, use rr on a virtualbox with windows in it :) :) :) :) :) 21:35
Nicholas I like rr 21:36
[Coke] ah, I did increase the level slightly 21:37
21:55 Altai-man 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!