01:48 ilbot3 joined
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:14
02:16 ggoebel18 joined 04:14 geekosaur joined 04:17 geekosaur joined 04:32 lizmat joined 05:56 geekosaur joined 07:15 zakharyas joined 07:23 domidumont joined 07:28 domidumont joined 07:49 vendethiel joined
nwc10 werda.geizhals.at/ -- spot the difference 08:46
oops, mischan 08:51
now, that resolves, but you shouldn't be able to get any content
09:34 vendethiel joined 09:47 diakopter joined 10:20 zakharyas joined 10:31 vendethiel joined 10:57 vendethiel joined
dalek arVM: 808fd05 | timotimo++ | src/strings/ops.c:
cope with buffers being too small in re_nfg

fixes a crash when working with utf8-c8 strings.		 12:06
timotimo ^- i'm not sure if this gives us the right semantics, but we're not crashing any more at least 12:07
12:30 zakharyas joined 12:46 vendethiel joined
nine timotimo: left some comments on the commit 13:02
timotimo ah, good catch on the second one 13:03
dalek arVM: fcee004 | timotimo++ | src/strings/ops.c:
fix references to buffer size to use the actual variable.
 13:04
nine Cool :) Demonstrating again, that even reviews by total newbies can help. 13:06
timotimo aye, i'm grateful
arnsholt Yeah, I like the commitbots more and more 13:12
Especially when the commit message is something that makes me go "I wonder how that was implemented"
timotimo if the first line contains "timo", it's probably "poorly" 13:13
doubly so, if it contains "timo" twice
16:04 vendethiel joined
diakopter lol 16:42
timotimo now things get a bit more interesting 16:52
afl found out that if you arg_o with a high number, you get a segfault
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
in the original bytecode verifier I had a TODO listed for that
it can at least be conservative 16:54
timotimo like "we're probably not going to have 1k arguments here, so complain" 16:55
diakopter well it can look at the arg puller 16:56
the thing that adds args
it can at least limit it to the number of those
timotimo the arg puller? 16:57
... the what now? :)
Unhandled exception: Tried to takeclosure a null object. 17:00
at <unknown>:1
(/tmp/minimized_output/crashes/id:000006,sig:11,src:000002,op:flip1,pos:107072:000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
how did this happen :D
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:01
17:03 domidumont joined
timotimo hm. 17:05
should i really put a null-check into assignunchecked?
like, what kind of guarantee do we give, what's the threat model? 17:08
17:33 vendethiel joined
timotimo diakopter: wanna diagnose a crash? 18:04
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:07
Unhandled exception: Too few positionals passed; expected 12336 arguments but got 0 18:20
sprinkling ALL the null checks 18:26
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
because then we'd have a VMNull object that would gracefully blow up
of course, branches and stuff make that hard 18:35
but i don't really feel like giving every single op out there an MVM_is_null and a exception_throw_adhoc
dalek arVM/many_null_checks: 70491b8 | timotimo++ | src/core/ (3 files):
WIP on making fuzzed bytecode less crashy

though perhaps there's a better way by making the validator smarter; if a register has been written to before it gets read, it'll surely be a proper VMNull, not an actual null pointer.		 18:37
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:46
jnthn timotimo: Well, the other option is to pre-populate object registers with VMNull 18:47
timotimo i also thought about that
don't we store vm-level null in some places to signify something?
is that only lexicals and attributes?
jnthn We use real NULLs in lexicals and attrs 18:48
For lazy viv
But not normal registers
We could drop doing it for specialized frames potentially, after further analysis. Or even detect lack of need for it during validation
timotimo should i build that solution?
jnthn It'd be better than NULL checks everywhere 18:49
timotimo quite
jnthn Branches everywhere considered bad
timotimo and repr checks would then automagically include the null check
jnthn aye 18:50
timotimo oh, i think i put the args range check in there, too 19:20
well, it's also very much not pretty :)
i'll be interested to see how we'll end up doing bigger registers, like long doubles 19:27
maybe a separate bit of space in "work" that is reserved for 2-64bit-pieces of space 19:33
and also a separate space for arguments in extra-big types
nine Why are Lexotics not serializable? 19:35
And...what exactly are they anyway?
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`
nine: They're the thing that is stored in the frame that has the return handler 19:37
nine Even implicit returns?
jnthn No 19:39
Though I think we code-gen one for every routine that might explicit return
The VM caches them also 19:40
I've been pondering killing them off in favor of real control exceptions though
The reason we have this approach dates back to the Parrot days
The caching creates problems of its own
timotimo i didn't know we could kill them off 19:47
bbl, food time
nine So probably not for an EVAL's return value either 19:59
timotimo my patch for initializing work with VMNull pointers survives spectests :) 20:32
it seems like the validator is already supposed to bail out when argument numbers are out of range 20:35
but for some reason it doesn't fire
maybe when we put in lazy deserialization we forgot to trigger bytecode validation at some point? 20:36
jnthn timotimo: Unlikely 20:44
dalek arVM: 9cce207 | timotimo++ | src/core/frame.c:
initialize objetc registers with VMNull when allocating frames

this ensures that even if we handle corrupt bytecode or broken code in general, that we get proper errors rather than segfaults.
jnthn timotimo: The validation and the rest of deserialization is triggered by the same flag, I think
timotimo right, i see now that the instrumentation barrier hit will cause the verification 20:46
that shouldn't be b0rked :)
otherwise we'd have bigger problems
oh wow, what the ... 20:50
1266 int save_errno = errno;
Cannot access memory at address 0x7fffff7fed0f
probably a stack overflow?
geekosaur um, is that even sensible these days? 20:51
errno usually expands to a function accessing thread local storage
timotimo tell that to whoever made _IO_vfprintf_internal
oh, holy hell 20:52
the stack *is* big
hah
it looks like we're trying to complain about something 20:53
and when building the stack trace, we notice the string index for a filename is way past the string heap's end
or something like that
so what do we do? we throw an exception warning about that :) 20:54
then we panic_unhandled_ex, dump_backtrace, exception_backtrace_line, cu_obtain_string, exception_throw_adhoc, panic_unhandled_ex, ... :) 20:55
pretty cool that afl-fuzz found this
hoelzro I love that name 20:58
timotimo yes! when i saw the picture that goes with the name on wikipedia, i knew i had to use that piece of software 20:59
afl-fuzz is gnawing on a really, really, really big file right now :\ 21:03
44.0 M execs for this phase, of which it has already done 1.28M :\ 21:04
hoelzro wow
timotimo but the expected amount goes down sometimes
it's 43.9M now 21:05
all in all, that instance of afl-fuzz has already executed moar 253M times over the last 4 days, 10 hours
did you look at the pretty graphs yet? hack.p6c.org/~timo/
hoelzro I haven't! 21:08
235 *million* times?
wow
timotimo one of the runs only goes to --dump 21:11
that's supposed to exercise the bytecode loader 21:12
the other one executes the .moarvm file in full
including dependencies, if there are any
wow, it got through that run that it claimed would take 44M execs 21:14
it seems to do some pretty agressive culling i guess
21:17 lizmat joined
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:44
moarvm github issue? 21:45
jnthn timotimo: Is it in RT? I can the end of that pretty often :) I think Tux already filed there today... :) 21:48
timotimo it doesn't result in a crash 21:50
can't tell if it corrupts data or not
jnthn invalid read is still bad
Note it on the RT maybe?
Will look there
Did you fix it some already? 21:51
timotimo yup
jnthn Cool...in master, or branch?
timotimo trouble was we were convinced the buffer in "re_nfg" wouldn't ever need to grow
jnthn ah
timotimo even had a comment saying we'd never need a bigger buffer than the initial guess
it's in master
jnthn heh, ok
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
jnthn oops
timotimo but nothing ensures that the arg calls are successive numbers, or all below the count
jnthn Validator has a few holes...
There's comments at the top about some of 'em, iirc 21:53
Anyway, resting :)
timotimo gnite!
"cur_frame->args indexes" is probably the one i'm looking at
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:00
diakopter buh indeed 22:08
22:14 Unavowed joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!