|
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
|
|||