|
01:46
FROGGS joined
01:48
ilbot3 joined
03:41
colomon joined
05:43
domidumont joined
05:47
lizmat joined
06:09
domidumont joined
06:12
domidumont joined
06:30
domidumont joined
|
|||
| nwc10 | good *, #moarvm | 07:07 | |
|
07:54
lizmat joined
08:15
brrt joined
|
|||
| brrt | good * #moarvm, nwc10 | 08:16 | |
| brrt won't be going to YAPC::EU this year | 08:22 | ||
| nine | :( | 08:42 | |
| brrt | can't be helped i'm afraid | 08:57 | |
|
09:21
zakharyas joined
10:23
colomon joined
10:59
brrt joined
11:37
stmuk_ joined
12:15
stmuk_ joined
12:19
lizmat joined
12:29
cognominal joined
13:03
lizmat joined
13:22
zakharyas joined
13:26
brrt joined
|
|||
| timotimo | aaw :| | 14:33 | |
| i wonder what afl-fuzz will find this time 'round | |||
|
17:36
lizmat joined
17:59
vendethiel joined
18:01
domidumont joined
18:29
FROGGS joined
19:58
japhb joined
|
|||
| 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:55 | |
| 235 handler_code = MVM_frame_find_invokee(tc, lh.frame->work[lh.handler->block_reg].o, NULL); | 20:56 | ||
| (gdb) print lh.frame->work[lh.handler->block_reg].o | |||
| $4 = (MVMObject *) 0x0 | |||
| in situations like these i'm not sure what a fix should look like | |||
| 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 | ||
| timotimo | surely we want to prevent an infinitely growing stack to be causable by a .moarvm file | 20:59 | |
| arnsholt | Yeah, that's probably a bug too | 21:00 | |
| Just abort() with a "this should never happen" message, maybe? | |||
| 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"); | ||
| (only semi-joking because strings like that are really easy to grep) | 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 | |||
| 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 | ||
| alternatively, to get the next-outer handler instead | |||
| mst | I don't think it's a terrible rule that if your exception handler throws an exception, you give up | ||
| 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 | ||
| maybe one of those is off-by-one | |||
| mst | maybe it's maybelline | 21:05 | |
| timotimo | running it under valgrind makes it die in another way | ||
| mst | (yes, sorry, not helping, stupid day) | ||
| timotimo | maybe that's why afl-fuzz put "havoc" in the file name :P | 21:06 | |
| mst | "cry havoc, and let slip the dogs of off by one errors" doesn't quite have the same ring to it | 21:07 | |
| timotimo | off by doge? | 21:08 | |
| here it seems like afl-fuzz found out it can give an arg_o opcode any unsigned 16 bit integer it likes | 21:12 | ||
| i think i've come across this particular thing in the past; i'd like to catch that in bytecode verification if possible | |||
| 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 | ||
| but ... ugh, the bytecode verifier is ... annoying to work on | |||