Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-04-11

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:14 zostay going back to the discussion of the abort issue, how is control exception resumability different from regular exceptions? aren't those resumable too?
02:16 ggoebel18 joined #moarvm
04:14 geekosaur joined #moarvm
04:17 geekosaur joined #moarvm
04:32 lizmat joined #moarvm
05:56 geekosaur joined #moarvm
07:15 zakharyas joined #moarvm
07:23 domidumont joined #moarvm
07:28 domidumont joined #moarvm
07:49 vendethiel joined #moarvm
08:46 nwc10 https://werda.geizhals.at/ -- spot the difference
08:51 nwc10 oops, mischan
08:51 nwc10 now, that resolves, but you shouldn't be able to get any content
09:34 vendethiel joined #moarvm
09:47 diakopter joined #moarvm
10:20 zakharyas joined #moarvm
10:31 vendethiel joined #moarvm
10:57 vendethiel joined #moarvm
12:06 dalek MoarVM: 808fd05 | timotimo++ | src/strings/ops.c:
12:06 dalek MoarVM: cope with buffers being too small in re_nfg
12:06 dalek MoarVM:
12:06 dalek MoarVM: fixes a crash when working with utf8-c8 strings.
12:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/808fd05041
12:07 timotimo ^- i'm not sure if this gives us the right semantics, but we're not crashing any more at least
12:30 zakharyas joined #moarvm
12:46 vendethiel joined #moarvm
13:02 nine timotimo: left some comments on the commit
13:03 timotimo ah, good catch on the second one
13:04 dalek MoarVM: fcee004 | timotimo++ | src/strings/ops.c:
13:04 dalek MoarVM: fix references to buffer size to use the actual variable.
13:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fcee004da2
13:06 nine Cool :) Demonstrating again, that even reviews by total newbies can help.
13:06 timotimo aye, i'm grateful
13:12 arnsholt Yeah, I like the commitbots more and more
13:12 arnsholt Especially when the commit message is something that makes me go "I wonder how that was implemented"
13:13 timotimo if the first line contains "timo", it's probably "poorly"
13:13 timotimo doubly so, if it contains "timo" twice
16:04 vendethiel joined #moarvm
16:42 diakopter lol
16:52 timotimo now things get a bit more interesting
16:52 timotimo afl found out that if you arg_o with a high number, you get a segfault
16:53 timotimo should we really put bounds checks into those operators? maybe the bytecode verifier could be able to handle this? not sure.
16:53 diakopter yeah it kinda should
16:53 diakopter in the original bytecode verifier I had a TODO listed for that
16:54 diakopter it can at least be conservative
16:55 timotimo like "we're probably not going to have 1k arguments here, so complain"
16:56 diakopter well it can look at the arg puller
16:56 diakopter the thing that adds args
16:56 diakopter it can at least limit it to the number of those
16:57 timotimo the arg puller?
16:57 timotimo ... the what now? :)
17:00 timotimo Unhandled exception: Tried to takeclosure a null object.
17:00 timotimo at <unknown>:1
17:00 timotimo (/tmp/minimized_output/crashes/id:000006,sig:11,src:000002,op:flip1,pos:107072:000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
17:00 timotimo 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
17:00 timotimo 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
17:00 timotimo how did this happen :D
17:01 timotimo well, "0" is the char that afl-tmin fills stuff up with when it has decided stuff is not interesting to the execution of the test case
17:03 domidumont joined #moarvm
17:05 timotimo hm.
17:05 timotimo should i really put a null-check into assignunchecked?
17:08 timotimo like, what kind of guarantee do we give, what's the threat model?
17:33 vendethiel joined #moarvm
18:04 timotimo diakopter: wanna diagnose a crash?
18:07 timotimo http://hack.p6c.org/~timo/crashes_after_update.tar.gz  -  the file with id 000017 does a crash in bytecode.c that my brane can't cope with right now
18:20 timotimo Unhandled exception: Too few positionals passed; expected 12336 arguments but got 0
18:26 timotimo sprinkling ALL the null checks
18:34 timotimo maybe some of these checks could be made unnecessary by the validator by making sure registers being used for stuff have been written to at least once before they are read from
18:34 timotimo because then we'd have a VMNull object that would gracefully blow up
18:35 timotimo of course, branches and stuff make that hard
18:35 timotimo but i don't really feel like giving every single op out there an MVM_is_null and a exception_throw_adhoc
18:37 dalek MoarVM/many_null_checks: 70491b8 | timotimo++ | src/core/ (3 files):
18:37 dalek MoarVM/many_null_checks: WIP on making fuzzed bytecode less crashy
18:37 dalek MoarVM/many_null_checks:
18:37 dalek MoarVM/many_null_checks: though perhaps there's a better way by making the
18:37 dalek MoarVM/many_null_checks: validator smarter; if a register has been written to
18:37 dalek MoarVM/many_null_checks: before it gets read, it'll surely be a proper VMNull,
18:37 dalek MoarVM/many_null_checks: not an actual null pointer.
18:37 dalek MoarVM/many_null_checks: review: https://github.com/MoarVM/MoarVM/commit/70491b8f9c
18:46 timotimo we could also have an instrumentation pass that runs every piece of code with extra null checks added to it when it's hit for the first time
18:47 jnthn timotimo: Well, the other option is to pre-populate object registers with VMNull
18:47 timotimo i also thought about that
18:47 timotimo don't we store vm-level null in some places to signify something?
18:47 timotimo is that only lexicals and attributes?
18:48 jnthn We use real NULLs in lexicals and attrs
18:48 jnthn For lazy viv
18:48 jnthn But not normal registers
18:48 jnthn We could drop doing it for specialized frames potentially, after further analysis. Or even detect lack of need for it during validation
18:48 timotimo should i build that solution?
18:49 jnthn It'd be better than NULL checks everywhere
18:49 timotimo quite
18:49 jnthn Branches everywhere considered bad
18:49 timotimo and repr checks would then automagically include the null check
18:50 jnthn aye
19:20 timotimo oh, i think i put the args range check in there, too
19:20 timotimo well, it's also very much not pretty :)
19:27 timotimo i'll be interested to see how we'll end up doing bigger registers, like long doubles
19:33 timotimo maybe a separate bit of space in "work" that is reserved for 2-64bit-pieces of space
19:33 timotimo and also a separate space for arguments in extra-big types
19:35 nine Why are Lexotics not serializable?
19:35 nine And...what exactly are they anyway?
19:36 nine The most interesting question would probably be how they end up in my shiny SC, but I fear, only another massive debugging quest will answer that
19:36 jnthn nine: They're involved in the implementation of `return`
19:37 jnthn nine: They're the thing that is stored in the frame that has the return handler
19:37 nine Even implicit returns?
19:39 jnthn No
19:39 jnthn Though I think we code-gen one for every routine that might explicit return
19:40 jnthn The VM caches them also
19:40 jnthn I've been pondering killing them off in favor of real control exceptions though
19:40 jnthn The reason we have this approach dates back to the Parrot days
19:40 jnthn The caching creates problems of its own
19:47 timotimo i didn't know we could kill them off
19:47 timotimo bbl, food time
19:59 nine So probably not for an EVAL's return value either
20:32 timotimo my patch for initializing work with VMNull pointers survives spectests :)
20:35 timotimo it seems like the validator is already supposed to bail out when argument numbers are out of range
20:35 timotimo but for some reason it doesn't fire
20:36 timotimo maybe when we put in lazy deserialization we forgot to trigger bytecode validation at some point?
20:44 jnthn timotimo: Unlikely
20:44 dalek MoarVM: 9cce207 | timotimo++ | src/core/frame.c:
20:44 dalek MoarVM: initialize objetc registers with VMNull when allocating frames
20:44 dalek MoarVM:
20:44 dalek MoarVM: this ensures that even if we handle corrupt bytecode
20:44 dalek MoarVM: or broken code in general, that we get proper errors rather
20:44 dalek MoarVM: than segfaults.
20:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9cce207931
20:44 jnthn timotimo: The validation and the rest of deserialization is triggered by the same flag, I think
20:46 timotimo right, i see now that the instrumentation barrier hit will cause the verification
20:46 timotimo that shouldn't be b0rked :)
20:46 timotimo otherwise we'd have bigger problems
20:50 timotimo oh wow, what the ...
20:50 timotimo 1266  int save_errno = errno;
20:50 timotimo Cannot access memory at address 0x7fffff7fed0f
20:50 timotimo probably a stack overflow?
20:51 geekosaur um, is that even sensible these days?
20:51 geekosaur errno usually expands to a function accessing thread local storage
20:51 timotimo tell that to whoever made _IO_vfprintf_internal
20:52 timotimo oh, holy hell
20:52 timotimo the stack *is* big
20:52 timotimo hah
20:53 timotimo it looks like we're trying to complain about something
20:53 timotimo and when building the stack trace, we notice the string index for a filename is way past the string heap's end
20:53 timotimo or something like that
20:54 timotimo so what do we do? we throw an exception warning about that :)
20:55 timotimo then we panic_unhandled_ex, dump_backtrace, exception_backtrace_line, cu_obtain_string, exception_throw_adhoc, panic_unhandled_ex, ... :)
20:55 timotimo pretty cool that afl-fuzz found this
20:58 hoelzro I love that name
20:59 timotimo yes! when i saw the picture that goes with the name on wikipedia, i knew i had to use that piece of software
21:03 timotimo afl-fuzz is gnawing on a really, really, really big file right now :\
21:04 timotimo 44.0 M execs for this phase, of which it has already done 1.28M :\
21:04 hoelzro wow
21:04 timotimo but the expected amount goes down sometimes
21:05 timotimo it's 43.9M now
21:05 timotimo all in all, that instance of afl-fuzz has already executed moar 253M times over the last 4 days, 10 hours
21:05 timotimo did you look at the pretty graphs yet? http://hack.p6c.org/~timo/
21:08 hoelzro I haven't!
21:08 hoelzro 235 *million* times?
21:08 hoelzro wow
21:11 timotimo one of the runs only goes to --dump
21:12 timotimo that's supposed to exercise the bytecode loader
21:12 timotimo the other one executes the .moarvm file in full
21:12 timotimo including dependencies, if there are any
21:14 timotimo wow, it got through that run that it claimed would take 44M execs
21:14 timotimo it seems to do some pretty agressive culling i guess
21:17 lizmat joined #moarvm
21:44 timotimo jnthn: how best to remind you that there's an invalid read off the end of the to-be-decoded utf8-c8 buffer and what line does it?
21:45 timotimo moarvm github issue?
21:48 jnthn timotimo: Is it in RT? I can the end of that pretty often :) I think Tux already filed there today... :)
21:50 timotimo it doesn't result in a crash
21:50 timotimo can't tell if it corrupts data or not
21:50 jnthn invalid read is still bad
21:50 jnthn Note it on the RT maybe?
21:50 jnthn Will look there
21:51 jnthn Did you fix it some already?
21:51 timotimo yup
21:51 jnthn Cool...in master, or branch?
21:51 timotimo trouble was we were convinced the buffer in "re_nfg" wouldn't ever need to grow
21:51 jnthn ah
21:51 timotimo even had a comment saying we'd never need a bigger buffer than the initial guess
21:51 timotimo it's in master
21:51 jnthn heh, ok
21:52 jnthn Well, rest time...maybe will look tomorrow. Otherwise Wed is, as usual, reserved for Perl 6 things :)
21:52 timotimo and the bytecode validator doesn't catch arg_* ops with obscene argument indices because it only checks if the number of calls is less than there are supposed to be args
21:52 jnthn oops
21:52 timotimo but nothing ensures that the arg calls are successive numbers, or all below the count
21:52 jnthn Validator has a few holes...
21:53 jnthn There's comments at the top about some of 'em, iirc
21:53 jnthn Anyway, resting :)
21:53 timotimo gnite!
21:53 timotimo "cur_frame->args indexes" is probably the one i'm looking at
22:00 timotimo buh, of course the validator works with the bytecode as a raw buffer and doesn't have things like the arguments nicely put into arrays and such
22:08 diakopter buh indeed
22:14 Unavowed joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary