| IRC logs at
Set by AlexDaniel on 12 June 2018.
MasterDuke heh, looks like the first thing it found is right 00:04
use after free
00:26 lucasb left 03:24 leont left 03:34 vesper11 left 03:35 vesper11 joined 04:36 vesper joined 04:37 vesper11 left 06:17 MasterDuke left
bartolin thanks, lizmat! (I just noticed that I asked in the wrong channel yesterday. I thought I was in raku-dev ...) 06:42
07:38 domidumont joined 07:47 patrickb joined 07:54 patrickb left 08:14 MasterDuke joined
nine timotimo: might be, yes 08:52
09:01 zakharyas joined
nwc10 good *, #moarvm 09:31
10:02 frost-lab joined
MasterDuke morning. looks like the clang analyzer correctly found some other problems (unfortunately, all the true positives so far have been my fault...) 10:12
jnthn morning o/ 10:13
nwc10 \o
jnthn: yes, (1 left shift (8 minus 5)) minus 1 is 7. I think that the comment could be clearer 10:14
timotimo MasterDuke: right, i think that wants to use "parent" instead of tc 10:44
MasterDuke hm, i just changed it to an MVM_panic
think throwing with parent is better? 10:45
timotimo it'll be a strange, possibly pathologic, situation when this error occurs, but i'm not sure if this is the right place to panic just yet
MasterDuke heh, easy fix 10:46
btw, it thinks could leak result_buffer_insert_pos, is that correct? 10:47
10:47 domidumont1 joined 10:49 domidumont left
timotimo looks right, i think a free before the return (and braces of course) would fix it 11:11
MasterDuke looks like some are needed before the panics also 11:14
11:33 domidumont1 left 11:47 domidumont joined 11:48 domidumont left 11:54 domidumont joined 12:06 domidumont left 12:26 domidumont joined
Geth MoarVM/master: 25 commits pushed by (Nicholas Clark)++
12:43 domidumont left 12:59 zakharyas left
lizmat nwc10: could you describe in one or more paragraphs what you did ? for the weekly? 13:05
13:10 domidumont joined
MasterDuke these lines don't do anything it seems since `ptr` is never used later. which makes the `char *ptr` introduced on the previous line useless. introduces it, but i don't see why 13:10
nm, the sprintfs to ptr write to node_label. clang analyzer got confused and so did i at first 13:20
timotimo: in it looks like there's a stray `return` that's still there
nwc10 lizmat: "or more' - last time "or more" was rather too much :-) 13:21
lizmat well... I don't think so, I thought it was worth an extra RWN edition :-)
nwc10 OK, so the "second'" part of the answer (first part not yet written or bailed out on) is that there are about 400 lines of comments at 13:22
lizmat hmmm.. that feels it needs a place in a docs/ ? 13:25
which I could do :-) 13:26
jnthn Dunno, the explanation being together with the code implementing it is maybe more likely to help those working on it?
lizmat true, but having it hidden in the code, is not inducive to getting more people wanting to work on it? 13:28
nwc10 I hadn't considered a separate document.
However, it seemed a more natural place to me at the time that I wrote it
and I'm not sure how much "work" it still needs
13:39 leont joined 13:49 lucasb joined
nwc10 lizmat: mailed. Briefly AFK to make tea 14:01
lizmat nwc10++
14:16 zakharyas joined 14:35 Kaiepi left 14:37 Kaiepi joined 14:39 frost-lab left 15:38 cog left 15:39 cog joined
nine nwc10: is there any good way to get at the address of a hash slot in gdb? I'd like to trace back, where a method got added to a method cache. 15:53
18:18 domidumont left 18:54 zakharyas left
nwc10 nince: OK, so I haven't tried this, but as the obvious answer seemms to be "call MVM_str_hash_fetch_nocheck" I assume that that isn't possible because it's an inline function? 18:55
lizmat and yet another Rakudo Weekly News hits the Net: 19:11
Geth MoarVM: MasterDuke17++ created pull request #1399:
Fix some simple things the clang static analyzer found
jnthn wow, busy week; lizmat++ 20:41
20:48 zakharyas joined
nine What I know so far (so that I don't forget): It breaks when multiple threads create the same mixin type concurrently. Once the type is in the cache, we're fine. The no such attribute error comes from bind_attribute being called with a class_handle from one of the losing threads, i.e. one of the types that doesn't end up in the cache. 21:03
The class_handle is from $?CLASS in the the role method's outer, i.e. the closure created during specialization. 21:04
Somehow that ends up in the winner's STable's method_cache
dogbert17 nine: have you tried tsan to see if it comes up with anything? 21:32
nine no 21:34
It's too consistent in its failure mode to be something like general memory corruption 21:35
With rr record -h --num-cores=16 --num-cpu-ticks=10 it's nicely reproducible
dogbert17 so you're not looking for a data race then? 21:37
nine Feels more like some piece of global state that we shouldn't have 21:46
Well, I'll find out more tomorrow
good night!
22:09 Kaiepi left 22:10 Kaiepi joined
dogbert17 ++nine 22:25
22:27 zakharyas left