Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-06-20

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

All times shown according to UTC.

Time Nick Message
01:46 FROGGS joined #moarvm
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
03:41 colomon joined #moarvm
05:43 domidumont joined #moarvm
05:47 lizmat joined #moarvm
06:09 domidumont joined #moarvm
06:12 domidumont joined #moarvm
06:30 domidumont joined #moarvm
07:07 nwc10 good *, #moarvm
07:54 lizmat joined #moarvm
08:15 brrt joined #moarvm
08:16 brrt good * #moarvm, nwc10
08:22 * brrt won't be going to YAPC::EU this year
08:42 nine :(
08:57 brrt can't be helped i'm afraid
09:21 zakharyas joined #moarvm
10:23 colomon joined #moarvm
10:59 brrt joined #moarvm
11:37 stmuk_ joined #moarvm
12:15 stmuk_ joined #moarvm
12:19 lizmat joined #moarvm
12:29 cognominal joined #moarvm
13:03 lizmat joined #moarvm
13:22 zakharyas joined #moarvm
13:26 brrt joined #moarvm
14:33 timotimo aaw :|
14:33 timotimo i wonder what afl-fuzz will find this time 'round
17:36 lizmat joined #moarvm
17:59 vendethiel joined #moarvm
18:01 domidumont joined #moarvm
18:29 FROGGS joined #moarvm
19:58 japhb joined #moarvm
20:55 timotimo it looks like afl-fuzz found a case where handling an exception causes a "cannot invoke null object" to be thrown, which will endlessly recurse through the exception handling machinery
20:56 timotimo 235             handler_code = MVM_frame_find_invokee(tc, lh.frame->work[lh.handler->block_reg].o, NULL);
20:56 timotimo (gdb) print lh.frame->work[lh.handler->block_reg].o
20:56 timotimo $4 = (MVMObject *) 0x0
20:56 timotimo in situations like these i'm not sure what a fix should look like
20:57 timotimo for future reference, that's fuzzerS1's crash number 60
20:57 arnsholt Sounds like the bug is somewhere else but causes this thing downstream. I'd suggest filing an issue for it and seeing what jnthn says
20:59 timotimo surely we want to prevent an infinitely growing stack to be causable by a .moarvm file
21:00 arnsholt Yeah, that's probably a bug too
21:00 arnsholt Just abort() with a "this should never happen" message, maybe?
21:01 arnsholt If it's a situation that can be detected easily, which it may very well not be from the sounds of it
21:01 mst timotimo: abort("Exception inception detection protection");
21:02 mst (only semi-joking because strings like that are really easy to grep)
21:02 timotimo %)
21:02 timotimo well, sometimes you do want to say "could not invoke a null object" and have exception handling further up have a chance to catch that
21:03 timotimo there'd have to be a way to check if the current handler that'd catch the exception is the same handler we're complaining about
21:03 timotimo alternatively, to get the next-outer handler instead
21:03 mst I don't think it's a terrible rule that if your exception handler throws an exception, you give up
21:04 mst diagnosing bugs where perl5 passed it outwards and things weirdly semi-worked was no fun at all
21:04 timotimo now here's a surprising one ... a MVM_serialization_read_int is segfaulting, even though it has some amount of "are we trying to read past the end?" protection in it
21:04 timotimo maybe one of those is off-by-one
21:05 mst maybe it's maybelline
21:05 timotimo running it under valgrind makes it die in another way
21:05 mst (yes, sorry, not helping, stupid day)
21:06 timotimo maybe that's why afl-fuzz put "havoc" in the file name :P
21:07 mst "cry havoc, and let slip the dogs of off by one errors" doesn't quite have the same ring to it
21:08 timotimo off by doge?
21:12 timotimo here it seems like afl-fuzz found out it can give an arg_o opcode any unsigned 16 bit integer it likes
21:12 timotimo i think i've come across this particular thing in the past; i'd like to catch that in bytecode verification if possible
21:13 timotimo the prepare args opcode that has to lead up to the arg_* calls ought to let me figure out how many arguments there can be maximum
21:13 timotimo but ... ugh, the bytecode verifier is ... annoying to work on

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