github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
01:24
lucasb left
02:17
Kaeipi left,
Kaeipi joined
03:22
earenndil joined,
moon-child left
03:53
earenndil is now known as moon-child
|
|||
nwc10 | good *, #moarvm | 06:27 | |
nine | Good *! | 07:36 | |
08:15
Altai-man joined
08:17
domidumont joined
08:34
zakharyas joined
09:02
vrurg left
09:43
MasterDuke joined
|
|||
jnthn | moarning o/ | 10:00 | |
tellable6 | 2021-01-16T21:43:45Z #moarvm <vrurg> jnthn commaide.com certificate has expired. | ||
2021-01-17T11:03:38Z #raku-dev <Xliff> jnthn a) Thanks and b) I know, I've joined it and is sending that .tell from #moarvm really a good way to get that message across? :) | |||
nwc10 | \o | 10:01 | |
MasterDuke | hello. really loving these "Invalid owner in item added to GC worklist" panics, so much fun to debug, even with rr | 10:11 | |
jnthn | At least with those you know what is adding the item, which is often a clue | 10:14 | |
MasterDuke | ? | 10:15 | |
jnthn | If the failure is discovered deep inside of the GC work loop, you don't easily know where the bogus pointer came from. Whereas the worklist ones, I think, always trigger from a gc_mark function | 10:16 | |
MasterDuke | MVM_gc_root_add_frame_registers_to_worklist, MVM_gc_root_add_frame_roots_to_worklist, MVM_gc_collect, run_gc, MVM_gc_enter_from_allocator, MVM_gc_allocate_nursery, fastcreate, MVM_interp_run | 10:17 | |
fwiw, this is happening after i added the indirection for spesh arg guards and candidates. it was working perfectly before that | 10:19 | ||
10:22
MasterDuke left
|
|||
jnthn | Ah, darn, the frame one is among the least useful... | 10:24 | |
I'll have some time soonish (afternoon maybe) to glance over the change | |||
10:29
MasterDuke joined
|
|||
MasterDuke | wish i knew why my connection has been so bad recently | 10:29 | |
current diff is here gist.github.com/MasterDuke17/fd236...07aad7722f (against github.com/MoarVM/MoarVM/pull/1344) | 10:30 | ||
oh. nqp builds if i disable the call to my new MVM_spesh_candidate_discard_one | 10:38 | ||
and rakudo | 10:42 | ||
ha. i'm so annoyed with myself right now. with the arg guard and candidate indirection, a normal build of moarvm + GC_DEBUG=1 and FSA_DEBUG=1 builds nqp and rakudo and passes a spectest. it's just MVM_spesh_candidate_discard_one that's the problem | 10:59 | ||
nine | So you narrowed it down :) | ||
MasterDuke | why didn't i implement the indirection first, and then add the removing of a candidate? who knows! | ||
it's only the single largest chunk of that diff, but for some reason i kept skipping over it thinking the problem was in adding the indirection, which was actually a simpler change | 11:00 | ||
arg...it's been something over a week or so i've been fighting this... | 11:01 | ||
oh well, yay for a holiday for me, but kid still going to school, gave me time to take a look with a fresh brain | 11:02 | ||
nine | MasterDuke: does check-roots.py find anything? | 11:16 | |
MasterDuke | oh, i haven't tried that | ||
11:17
brrt joined
|
|||
MasterDuke | doesn't looks like there's anything new | 11:20 | |
brrt | \o | 11:21 | |
nwc10 | o/ | 11:23 | |
11:32
sena_kun joined
11:33
Altai-man left
|
|||
nine | MasterDuke: what kind of object is it complaining about? | 11:35 | |
MasterDuke | well, now i'm getting a segfault in MVM_str_hash_key_is_valid | 11:37 | |
after re-enabling the call to MVM_spesh_candidate_discard_one | |||
gist.github.com/MasterDuke17/45562...cb81717c9f my code isn't anywhere in these backtraces, but i guess my memcpy could be at fault? | 11:43 | ||
nine | From what I see you modified data structures that hold pointers to GC collectables like MVMStaticFrameSpeshBody. Are you sure you adapted all gc_mark functions accordingly? | 11:49 | |
MVMSpeshCandidatesAndArgGuards holds a MVMSpeshCandidate **spesh_candidates. You changed MVMSpeshCandidate to be a collectable, didn't you? Are the array members gc_marked? | 11:51 | ||
11:52
brrt left,
MasterDuke left
12:09
MasterDuke joined
12:14
zakharyas left
|
|||
MasterDuke | nine: not sure why it didn't show up in the diff, but gist.github.com/MasterDuke17/19856...883bb87d06 shows the current gc_mark in src/6model/reprs/MVMStaticFrameSpesh.c | 12:15 | |
nine | Don't see anything obvious. I think rr is still your best bet | 12:44 | |
12:45
jpf1 left
12:56
rba left,
dogbert17 left,
samcv left
12:59
rba joined,
dogbert17 joined,
samcv joined,
Geth left
13:10
Kaeipi left
13:11
Kaeipi joined,
jpf1 joined
13:41
zakharyas joined
13:48
MasterDuke left
14:07
vrurg joined
14:10
patrickb joined
14:18
patrickb left
14:24
patrickb joined
14:27
lucasb joined
14:50
MasterDuke joined
|
|||
MasterDuke | hm, in MVM_spesh_candidate_discard_one, do i need to do something like the `MVM_ASSIGN_REF(tc, &(spesh->common.header), new_candidate_list[spesh->body.num_spesh_candidates], candidate);` that was added to MVM_spesh_candidate_add ? | 14:59 | |
15:27
patrickb left
15:31
Altai-man joined
15:33
sena_kun left
15:34
patrickb joined
15:49
MasterDuke left
|
|||
lizmat | and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/01/18/2021-...se-topped/ | 16:34 | |
patrickb | lizmat++ | 17:07 | |
17:10
patrickb left
18:11
patrickb joined
18:47
brrt joined
18:54
zakharyas left
19:01
domidumont left
19:32
sena_kun joined
19:34
Altai-man left
19:39
domidumont joined
19:54
domidumont left
20:04
zakharyas joined
20:19
patrickb left
20:23
patrickb joined
20:44
brrt left
20:54
vrurg left,
vrurg_ joined
22:06
zakharyas left
22:41
sena_kun left
22:43
sivoais joined
22:49
patrickb left
|