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:10 kjp joined 00:49 releasable6 joined 00:50 statisfiable6 joined, bloatable6 joined 01:03 reportable6 joined 01:05 dogbert11 joined 01:08 dogbert17 left 01:50 linkable6 joined 03:02 nine left, nine joined 03:48 greppable6 joined 03:49 nativecallable6 joined 04:13 lizmat_ joined, RakuIRCLogger left 04:14 TempIRCLogger left, lizmat left 04:15 Geth left 05:15 statisfiable6 left, squashable6 left, quotable6 left, bloatable6 left, tellable6 left, bisectable6 left, linkable6 left, releasable6 left, greppable6 left, sourceable6 left, coverable6 left, evalable6 left, committable6 left, shareable6 left, unicodable6 left, notable6 left, reportable6 left, nativecallable6 left, benchable6 left, reportable6 joined 05:16 committable6 joined, linkable6 joined 05:17 coverable6 joined, quotable6 joined, evalable6 joined 05:18 shareable6 joined, squashable6 joined 06:02 psydroid left, reportable6 left 06:10 psydroid joined 06:17 nativecallable6 joined 06:18 sourceable6 joined, benchable6 joined, tellable6 joined 07:04 reportable6 joined 07:15 statisfiable6 joined, bisectable6 joined 07:17 notable6 joined, greppable6 joined 08:16 unicodable6 joined 08:25 Geth joined 08:26 lizmat_ left, TempIRCLogger joined, lizmat joined 08:28 dogbert11 left, dogbert17 joined 08:35 dogbert11 joined 08:37 dogbert17 left 08:44 dogbert17 joined 08:46 dogbert11 left 08:50 dogbert11 joined 08:53 dogbert17 left 08:56 dogbert11 left, dogbert11 joined
Geth MoarVM: cd809ee472 | (Stefan Seifert)++ | src/6model/containers.c
Fix possible access to fromspace in code_pair_configure_container_spec

MVM_string_ascii_decode_nt allocates, so fetch can get moved during decoding of store.		 09:05
nine dogbert11: this ^^^ fixes t/spec/S06-routine-modifiers/proxy.t. Thankfully it was a very straigt forward GC issue :) 09:06
09:12 dogbert17 joined 09:16 dogbert11 left 09:17 releasable6 joined
dogbert17 nine++, so no rabbit hole this time :) 09:23
09:52 dogbert11 joined 09:55 dogbert17 left 10:03 dogbert17 joined 10:04 dogbert11 left
timo :+1: 10:32
i guess contspecs are only created very very early
nine There may be a rabbit hole after all. I switched back to the new-disp-nativecall branch and accidentally run that test again instead of the one I wanted to continue on. And it segfaulted. 10:53
It does so reproducibly due to a broken frame in dispatch. Now I wonder: is this something that's simply already fixed on master and my branch lacks that fix? Or is it something that my branch just unveils due to different memory layout or something like that. Or maybe even a direct regression. 10:54
11:04 linkable6 left, evalable6 left
dogbert17 oh, so there was a rabbit hole after all :) 11:11
nine Ok, it's not a fix in master that the branch lacks 11:16
11:17 bloatable6 joined
nine According to my bisection result it's 93bfeab1ee3d62e1ba7415c3894d2c5803a947b7 "Remove old invoke protocol" 11:18
lizmat aww
nine Of all the commits in my branch, this one makes the most sense as it makes changes to frame allocation 11:19
The segfault seems to be caused by overwriting unrelated memory when promoting a frame to the heap, which could be due to miscalculating frame size 11:20
dogbert17 it's good that you found it 11:27
perhaps I should emulate timo and suggest rr :)
nine No need. That's how I know that its overwriting unrelated memory 11:34
timo nine's computer go brr 11:43
nine This is odd. jnthnwrthngtn++ recently changed it so a frame's work registeres are allocated on the callstack, basically as part of the frame. Yet MVM_frame_move_to_heap does not deal with work registers at all. The work pointer is just copied from the frame on the callstack and will still point into the callstack. 11:46
Now this looks very much like a simple oversight and could cause such interesting issues. But it also sounds like it would wreak havoc long before my branch. 11:47
Ah, I may just misunderstand things. Apparently the original callstack entry of the frame will remain 11:50
timo maybe this is about whether we'll run code in there again?
work is not accessible to inner frames and such, only the lexicals
12:02 reportable6 left 12:04 evalable6 joined 12:06 linkable6 joined
nine Oh what a perfect way to waste some time. Pro tip: after switching branches touching MoarVM headers, recompile rakudo. 12:52
nine can't wait to see extops gone
timo d'oh 12:57
12:58 frost joined 13:04 reportable6 joined
lizmat And yet another Rakudo Weekly news hits the Net: rakudoweekly.blog/2021/11/01/2021-...0-rakoons/ 13:38
Geth MoarVM: 0821570aaa | (Stefan Seifert)++ | src/6model/containers.c
Avoid MVMROOT by better sequencing of the code

zhuomingliang++ for suggesting this much better version of the GC issue fix
13:49 frost left
jnthnwrthngtn nine: The lifetime of ->work is always that of the dynamic scope of the frame, which is precisely the lifetime of the callstack record, so there's no need to move that (unlike the environment, which can - in a promoted frame - outlive the dynamic scope) 13:59
This is very much by design, not an oversight.
nine At least that motivated me to have a look at the remaining extops. Couldn't RAKUDO_FIRST_FLAG easily be replaced with a state var? 14:11
jnthnwrthngtn Cheaper in terms of keeping the loop body inlinable would be a secret lexical in the outer scope. 14:12
(We can't inline things with state vars, I'm not really hurrying to implement that, and it's probably easier to implement it as a lexical in the scope where the loop appears anyway)
timo it can't be a local from the start? 14:17
oh, only after inlining, of course
14:51 Altai-man joined, Voldenet left, Altai-man left 14:54 Voldenet joined 16:02 Voldenet left 16:07 Voldenet joined
dogbert17 Already set resume init args for this dispatcher 17:55
in block at t/spec/S02-types/range.t line 424
in sub subtest at /home/dogbert/repos/rakudo/lib/Test.rakumod (Test) line 437
this pops up when running with a (very) small nursery and MVM_SPESH_BLOCKING=1 plus MVM_SPESH_NODELAY=1 17:56
timo the --ll-exception here could be interesting 17:57
dogbert17 timo: gist.github.com/dogbert17/9c648c7e...c6e046b573 18:01
timo and dump_bytecode from inside that dispatcher as well
dogbert17 aha
timo did we get any further for the "need to use tracked capture" one from the other day? that was you with a small nursery as well wasn't it? 18:02
18:02 reportable6 left 18:04 reportable6 joined
dogbert17 timo: gist updated 18:05
the other bug didn't want to show itself when nine tried to repro :( 18:06
timo ok, so the only way to reach that error message is through the syscall dispatcher-set-resume-init-args 18:18
and there's only one call to that in our dumped bytecode
and this is the boot-resume-caller dispatcher i assume 18:20
i think my local v6c.nqp from BOOTSTRAP doesn't match the line numbers supplied 18:21
ok, i'm still on my branch so no big surprise
what's that line on your machine there? 18:22
might be interesting to see the contents of the record->rec.resume_inits 18:30
dogbert17 6481 # Initialization of a non-trivial dispatch. Receives a dispatch resumption 18:55
6482 # kind, which is zero if we're not resuming.
6483 -> $capture {
6484 # Extract and guard on the kind (first argument).
running it under gdb led to a 'MoarVM panic: Adding pointer 0x555555686208 to past fromspace to GC worklist' 19:01
(gdb) p *record->rec.resume_inits 19:06
$3 = {disp = 0x555556c9c698, capture = 0x55555555bc18}
I updated the gist with some info about the panic, perhaps nine++ can make something of that 19:12
timo so perhaps we're not marking everything in these records 19:45
19:53 Kaiepi left, Kaiepi joined 20:12 linkable6 left
timo how many resume inits are in there? you'll want to print the entire record->rec actually, forgot how that works 20:21
dogbert17 (gdb) p record->rec 20:37
$7 = {initial_capture = {capture = 0x55555555b2b0, transformation = MVMDispProgramRecordingInitial, index = 21845, value_index = 1516444472, captures = 0x55555a6a3490, captures_num = 1, captures_alloc = 8},
resume_kind = MVMDispProgramRecordingResumeCaller, inline_cache_size = 1, resumptions = 0x55555a69d6d0, resumptions_num = 3, resumptions_alloc = 4, values = 0x55555a6a4ac0, values_num = 26,
values_alloc = 34, resume_inits = 0x55555a69c7b0, resume_inits_num = 1, resume_inits_alloc = 4, outcome_value = 1516458416, outcome_capture = 0x0, bind_failure_resumption_flag = 1484418240,
bind_success_resumption_flag = 21845, map_bind_outcome_to_resumption = MVMDispProgramRecordingBindControlNone, do_not_install = 0 '\000'}
japhb What's with all the hex 5's? 20:41
timo ok so there's just the one resume_inits, the one you already posted, with the disp and the capture 20:42
japhb (BTW, I'm not actually just being silly, strings of 0101 are often used as sentinels, so it is really weird seeing it so much here.) 20:43
timo dogbert17 could give us the output of /proc/$pid/maps (or i guess gdb probably has a command that does something similar) where these address ranges live 20:44
dogbert17 timo: gist updated 20:53
timo ok the 5s are harmless then
japhb Weird, but yeah, I suppose so. 21:54
22:13 linkable6 joined 23:39 evalable6 left, linkable6 left 23:43 dogbert17 left 23:46 dogbert17 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!