github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo dunno, what happens in the last few events leading up to the sigkill? 00:27
00:40 TimToady left 00:45 TimToady joined 01:35 Altai-man_ joined 01:38 sena_kun left 02:07 Kaiepi left 02:08 Kaiepi joined 03:36 sena_kun joined 03:38 Altai-man_ left 05:35 Altai-man_ joined 05:38 sena_kun left
nwc10 good *, #moarvm 06:39
Geth_ MoarVM/prefer-lexical_names_list: c8786043a5 | (Nicholas Clark)++ | 3 files
Where possible, iterate over lexical_names_list instead of lexical_names.

The former is an array, the latter a hash. Given that they have the same contents, it's much simpler to iterate over the list.
06:45
MoarVM/prefer-lexical_names_list: 960a21187a | (Nicholas Clark)++ | 7 files
Wrap all access to lexical_names with MVM_get_lexical_by_name.

This permits us to easily tweak the storage format.
The "Indexes were formerly stored off-by-one" comment related to code before 2013, back when hashes were implemented with the Apache Portable Runtime. I don't think that it's useful to retain it. :-)
MoarVM/prefer-lexical_names_list: e24eb0f0df | (Nicholas Clark)++ | 2 files
Don't make a lookup hash for lexical names for frames with few lexicals.

If there are 5 or fewer lexicals in the static frame, don't create a lookup hash for them. Instead, find them by a linear scan of the list. For a short list, this won't be slower, and we save some memory.
The value 5 is an educated guess - there might be a better cut-over point. ... (5 more lines)
MoarVM: nwc10++ created pull request #1307:
Prefer lexical names list
06:53
07:36 sena_kun joined 07:38 Altai-man_ left 07:48 zakharyas joined
MasterDuke timotimo: `reverse-next` after it gets the kill just gives `Cannot find bounds of current function` 08:23
but i can `reverse-continue` and then quickly hit ctrl-c 08:24
and `reverse-next` from there 08:25
ok, i'm up in `run_gc`, which is in QAST.nqp's `assemble_to_file` 08:28
08:29 leont joined
nine MasterDuke: I had a quick look in gdb and I'm stumped. I get an "Invalid owner in item added to GC worklist" MVM_panic in 1392 MVM_gc_worklist_add(tc, worklist, &g->sf); 08:56
But: (gdb) p (*(MVMCollectable **)(&g->sf))->owner
$7 = 1
1 is cleary a valid owner
MasterDuke i don't know anything about owners. i'll admit that i am unlikely to be very good at debugging this 09:07
nine The owner is just the number of the thread that allocated an object out of its memory. Each thread manages its own memory 09:10
MasterDuke ah, that's good to know
is 0 a usual value for `tc->instance->next_user_thread_id`? 09:13
nine no?
MasterDuke github.com/MoarVM/MoarVM/blob/mast...list.h#L40 the condition that seems to be firing 09:15
lizmat r: dd $*THREAD.id 09:21
camelia 12
1
lizmat hmmm
sorta expected 0 :-) 09:22
MasterDuke p (*(MVMCollectable **)(&g->sf))->owner
$1 = 1
p tc->instance->next_user_thread_id
$2 = 3 09:23
?
how is 1 > 3 ? 09:24
09:35 Altai-man_ joined 09:38 sena_kun left
MasterDuke ha. if i add the values to the panic message: `MoarVM panic: Invalid owner in item added to GC worklist, 374917472 > 3` 09:49
lizmat 1658C960 in hex, feels like an address 09:52
jnthn Those usually don't mean too much more than "memory corruption"
MasterDuke: Are you debugging with an optimized build? 'cus I never trust the values out of one of those...
MasterDuke yeah...guess i should turn it off. but no optimization and MVM_GC_DEBUG = 3...ugh 09:54
nwc10 \o
jnthn o/ 09:55
MasterDuke MoarVM panic: Invalid owner in item added to GC worklist, 1960663392 > 3 09:56
nine MasterDuke: you really want --debug --optimize=0. You lose much more time by chasing wrong leads than by waiting for the slower VM. 09:57
MasterDuke so it panics because some corruption is causing the comparison to incorrectly fail. but when inspected in gdb the value is fine? 10:15
oh 10:17
it's now pointing at src/spesh/graph.c:1409, not 1392
(gdb) p (*(MVMCollectable **)(&(g->facts[i][j].value.s)))->owner 10:18
$4 = 1431697760
could it be my MVM_spesh_usages_delete_by_reg calls? if those are incorrect could that cause this sort of problem? 10:30
github.com/MoarVM/MoarVM/blob/mast...ze.c#L1338 and github.com/MoarVM/MoarVM/blob/mast...ze.c#L1345 10:31
ok, so just commenting out github.com/MoarVM/MoarVM/blob/mast...ze.c#L1350 `sym_facts->value.i = (MVMint64)entry;` (and removing the `*_(un)blocked()` calls) seems to have got things working 10:57
11:08 zakharyas left 11:25 MasterDuke left 11:36 sena_kun joined 11:38 Altai-man_ left 11:48 MasterDuke joined 12:08 zakharyas joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/06/08/2020-...0-rakoons/ 13:01
13:35 Altai-man_ joined
MasterDuke heh. slight interruption from a power loss, but i'm not sure i'm going to finish this MVM_GC_DEBUG =3 build+test. i think it's been just building nqp for the past hour and still isn't finished 13:37
13:38 sena_kun left
timotimo MasterDuke:just build it without GC_DEBUG 14:30
and only run the problematic part with the debug stuff and rr and such
MasterDuke i did that and everything worked fine 14:34
thought i'd give a go at doing the whole thing with MVM_GC_DEBUG =3. but i'd just stopped it a couple min ago, it was killing my computer 14:35
i.e., the part that was reliably failing with MVM_GC_DEBUG =3 now succeeds with MVM_GC_DEBUG =3. i also did a complete run of everything with MVM_GC_DEBUG = 0 and it all worked fine 14:37
however, i'm not convinced that the change i made is completely sufficient/correct, but i don't know enough to be sure either way 14:38
timotimo hmm 14:42
15:36 sena_kun joined 15:38 Altai-man_ left
Geth_ MoarVM: MasterDuke17++ created pull request #1308:
Maybe fix MVM_panic from entering GC during spesh
16:43
17:35 Altai-man_ joined 17:38 sena_kun left
timotimo MasterDuke: i think you're writing to the facts of the symbol that's being looked up, not the thing being returned 17:44
actually, no, that's the known value of the pointer value?
17:48 zakharyas left
timotimo FWIW we can save the re-allocation of the smaller operand array since i don't think we're using anything from there afterwards 17:48
since it's the ins->info that determines how many operands we'll try to access in other places 17:50
oh hold up 17:56
sp_gethashentryvalue's first argument is a literal, not a register
literals don't have facts, only registers do 17:57
i'm only not merging it yet because it's marked draft and perhaps an additional review would be good 18:07
18:16 lucasb joined
MasterDuke timotimo: ah, so i'll remove the reallocation. should i also remove the `MVM_spesh_use_facts(tc, g, sym_facts);` 18:32
?
what about the `MVM_spesh_usages_delete_by_reg` calls, are those correct?
timotimo leave it be; we've used the knowledge of the value to figure out what hash entry to get, after all
i think those are correct 18:33
i believe i might have asked this recently, but do we regularly run with DU_CHECK (whatever it's called)? does nwc do thet? 18:34
MasterDuke i think he mentioned some results recently (month or two ago) 18:37
18:47 zakharyas joined 19:36 sena_kun joined 19:38 Altai-man_ left 19:58 zakharyas left 21:35 Altai-man_ joined 21:38 sena_kun left 22:15 leont left 22:41 dogbert11 left 23:34 dogbert11 joined 23:37 sena_kun joined 23:39 Altai-man_ left