|
03:42
vendethiel- joined
|
|||
| nine | japhb: I have used fprintf(stderr, ...) so far and never had a problem with it | 06:40 | |
|
07:08
lizmat joined
07:12
lizmat_ joined
07:15
lizmat joined
07:17
lizmat__ joined
07:19
lizmat_ joined
07:37
zakharyas joined
07:39
domidumont joined
07:44
domidumont joined
08:31
TheLemonMan joined
09:41
zakharyas joined
10:00
zakharyas joined
11:16
domidumont joined
13:03
domidumont1 joined
|
|||
| japhb | nine: Yeah, after I logged off for the night, I realized I hadn't just tried the obvious; I was so used to MoarVM redefining basic things like malloc, that it hadn't at first occurred to me that would work unchanged. :-) | 14:36 | |
|
16:06
Util joined
16:16
lizmat joined
16:17
zakharyas joined
|
|||
| dalek | arVM: e22afbe | LemonBoy++ | src/6model/serialization.c: Do not crash when the container config can't be read. |
16:29 | |
| arVM: ff6b62b | jnthn++ | src/6model/serialization.c: Merge pull request #394 from LemonBoy/dont-crash Do not crash when the container config can't be read. |
|||
| TheLemonMan | jnthn, I think you've accidentally broken the codegen for functions with a slurpy parameter that has a default value (in github.com/perl6/nqp/commit/b4363405) | 16:33 | |
| jnthn | ...slurpy parameter with a default? | 16:34 | |
| If that's ever been supported it's by accident | |||
| TheLemonMan | m: sub bar (|args = \(1,2,3)) {...} | ||
| camelia | rakudo-moar 668dc5: OUTPUT«===SORRY!===At Frame 2, Instruction 4, op 'param_sp' has invalid number (3) of operands; needs 2.» | ||
| TheLemonMan | j: sub bar (|args = \(1,2,3)) {...} | ||
| jnthn | m: sub foo(*@a = 1) { } | ||
| camelia | ( no output ) | ||
| rakudo-moar 668dc5: OUTPUT«===SORRY!=== Error while compiling <tmp>Cannot put default on slurpy parameter @aat <tmp>:1------> sub foo(*@a = 1⏏) { } expecting any of: constraint» | |||
| jnthn | It should give an error like that | 16:35 | |
| (e.g. should be caught at Rakudo level as invalid) | |||
| TheLemonMan | cool, let me write a quick patch then | ||
| jnthn | :) | ||
|
16:47
domidumont joined
|
|||
| TheLemonMan | done! | 17:19 | |
| [Coke] is happy to see another moarvm hacker! | 17:31 | ||
|
17:49
ilbot3 joined
|
|||
| TheLemonMan | jnthn, I think there's something wrong here (github.com/MoarVM/MoarVM/blob/mast...ame.c#L270 github.com/MoarVM/MoarVM/blob/mast...e.c#L290), frame->args is always bound to point right after the end of the malloc'd memory causing all sort of silent heap corruption | 18:41 | |
| WRT RT#128705, I managed to pin-point it after disabling the jit and compiling with --debug --no-optimize | 18:42 | ||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128705 | ||
| TheLemonMan | I tried making the workspace bigger and observed no more problems in the valgrind output | 18:43 | |
| timotimo | btw github lets you highlight ranges of code with #l123-l999 syntax in urls | 18:45 | |
| im using my phone right now, makes it hard to read that code | 18:46 | ||
| jnthn | TheLemonMan: work_size is meant to factor in argument buffer space, mind... | ||
| github.com/MoarVM/MoarVM/blob/mast...rame.c#L31 | |||
| It does it there, for example | |||
| I wonder if it somehow misses it in spesh'd frames... | 18:47 | ||
| timotimo | ill either look at rejecting frames that would segv by accessing past the params buffer or intto making the inlined bbs in spesh be properly checked | 18:48 | |
| today that is | |||
| jnthn | TheLemonMan: Hmm, that doesn't seem to be it: github.com/MoarVM/MoarVM/blob/mast...idate.c#L5 | 18:49 | |
| TheLemonMan: Though I'm curious, does the problem go away with MVM_SPESH_INLINE_DISABLE=1 too? | |||
| timotimo | the former will make a crapton of crashes afl-fuzz found "harmless" | ||
| TheLemonMan | disabling the spesh makes the problem go away (I always forget about the spesh :\) | ||
| jnthn | What about inline specifically though? | 18:50 | |
| TheLemonMan | let me try | ||
| timotimo | the latter is an important step towards preventing a bit of boxing +unboxing | ||
| TheLemonMan | yeah, no problem | ||
| jnthn | I'm wondering if the failure mode is that we inline something from a comp unit with a bigger max callsite size | ||
| timotimo | that sounds like an interesting failure mode | 18:51 | |
| jnthn | For example, if the current compilation unit only ever uses 4 slots, but we inline a callee, which in turn makes a non-inlined call to something that uses 6 slots, we'd be in bother. | ||
| I *think* the best way to fix it would be in github.com/MoarVM/MoarVM/blob/mast...idate.c#L5 | 18:52 | ||
| Iterate over the inlines array, looking at the static_frame->body.comp_unit or so, which in turn has a max_callsite size | |||
| And pick the max of the maxes | |||
| timotimo | the extreme! | ||
| jnthn | Transitive inlines should still be fine that way because we embed the inlinee's inlines table in ours too. | 18:53 | |
| Nice find, btw :) | |||
| timotimo | im pretty glad to see a new conztibitor around here :-) | 18:57 | |
| jnthn | Me too :) | ||
| TheLemonMan | yeah, that was it, it's either the correct solution or just a nice way to stop that from crashing heh | 19:03 | |
| jnthn | Well, it's at least necessary. Sufficient is harder. :) | 19:12 | |
| dinner & | 19:13 | ||
| TheLemonMan | PR sent :) | 19:14 | |
|
19:14
zakharyas joined
19:19
Ven joined
|
|||
| TheLemonMan | anyway, if anyone manages to find out what's needed to run the output of perl6 --output=mbc with moarvm please let me know, I can repay you with patches :) | 19:50 | |
| TheLemonMan &| | |||
| dalek | arVM: a23c536 | LemonBoy++ | src/spesh/candidate.c: Correctly calculate the work_size when the inlining is enabled. Thanks to @jnthn for pinpointing the problem. |
20:02 | |
| arVM: a3c00d5 | jnthn++ | src/spesh/candidate.c: Merge pull request #395 from LemonBoy/spesh-inline-callsize Correctly calculate the work_size when the inlining is enabled. |
|||
|
20:11
brrt joined
|
|||
| timotimo | oooh | 20:24 | |
| timotimo has a pear cider | |||
| my food is ready to be eated | 20:28 | ||
|
20:45
Ven joined
20:46
sivoais joined
|
|||
| timotimo is spec testing a first attempt at the checkarity thing for the bytecode validator | 21:28 | ||
| it doesn't seem to asplode any spec tests at least | 21:31 | ||
| dalek | arVM: bca85b2 | timotimo++ | src/core/ (3 files): validate indices of param_ ops we can already identify b0rked frames in the bytecode validation phase in this aspect. afl-fuzzy was able to create a crapton of crashing cases based on the access to param buffers not being bounds-checked at all. Now instead of paying a little bit for a bounds check on every single param access, we make validation a bit smarter up-front. |
21:41 | |
| jnthn | Nice | 21:59 | |
| Note that we should perhaps also handle the case wehre we have param ops but didn't see a checkarity yet | |||
| Which would also be illegal | |||
| timotimo | ah, good point | 22:01 | |
| i think at this point it'll read an uninitialized value | |||
| dalek | arVM: 4fc41d5 | timotimo++ | src/core/validation.c: init new field and require checkarity before param_* |
22:13 | |
| arVM: 4906666 | timotimo++ | src/core/validation.c: uncuddle an else |
|||
| timotimo | afl-fuzzy finds crashes pretty much immediately again :) | 22:34 | |
| a bunch of crashy things in autoclose | 22:42 | ||