github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke heh, looks like the first thing it found is right 00:04
use after free github.com/MoarVM/MoarVM/blob/mast...text.c#L55
bartolin thanks, lizmat! (I just noticed that I asked in the wrong channel yesterday. I thought I was in raku-dev ...) 06:42
nine timotimo: might be, yes 08:52
nwc10 good *, #moarvm 09:31
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 github.com/MoarVM/MoarVM/blob/mast...ot.c#L1005 could leak result_buffer_insert_pos, is that correct? 10:47
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
Geth MoarVM/master: 25 commits pushed by (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/5...94b666f683		 12:35
lizmat nwc10: could you describe in one or more paragraphs what you did ? for the weekly? 13:05
MasterDuke these lines github.com/MoarVM/MoarVM/blame/mas....c#L76-L82 don't do anything it seems since `ptr` is never used later. which makes the `char *ptr` introduced on the previous line useless. github.com/MoarVM/MoarVM/commit/01...bbb7fcbd57 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 github.com/MoarVM/MoarVM/commit/9d...8c4e950dde 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
github.com/MoarVM/MoarVM/blob/mast...sh_table.h
lizmat hmmm.. that feels it needs a place in a docs/hash-implementation.md ? 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
nwc10 lizmat: mailed. Briefly AFK to make tea 14:01
lizmat nwc10++
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
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
nine^
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/12/07/2020-...haping-up/ 19:11
Geth MoarVM: MasterDuke17++ created pull request #1399:
Fix some simple things the clang static analyzer found		 19:57
jnthn wow, busy week; lizmat++ 20:41
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!
dogbert17 ++nine 22:25

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!