Very true; but that's exactly the reason why I think it's a good idea to turn them into a CHECK. Rather than having weirdly behaving websites (who catch illegal access exceptions?), we'll actually start getting feedback about where the bugs are.
On Thu, Oct 15, 2015 at 3:31 PM Adam Klein <[email protected]> wrote: > I think "uncomfortably excited" is exactly the right term to describe my > feelings about this proposal. > > It's pretty scary (who knows how often we hit these in production?), but I > buy that (1) and (2) are both things that we should catch, and crashing is > definitely a way to make sure we find out about them. > > On Thu, Oct 15, 2015 at 3:15 PM, Michael Starzinger < > [email protected]> wrote: > >> *TL;DR*: I propose to convert (almost) all RUNTIME_ASSERT into CHECK >> macros. >> >> We make heavy use of RUNTIME_ASSERT to check preconditions for our >> runtime functions (i.e. everything in src/runtime/runtime-*.cc files), >> which in turn will cause an "illegal access" string to be thrown if the >> precondition is violated. As far as I am aware, there are only three cases >> of how preconditions could be violated: >> >> 1) Builtin functions that use runtime calls have a bug. >> 2) Compilers that directly emit runtime calls have a bug. >> 3) Third-party code is running with --allow-natives-syntax and is >> abusing runtime calls. >> >> For all three cases I think we should not continue executing (i.e. >> throwing an exception), but instead should abort execution immediately and >> crash hard (even in release mode). This would give us feedback about bugs >> for (1) and (2) happening in the wild. There is a small set of runtime >> functions (i.e. a white-list of three runtime calls) that ClusterFuzz uses >> while generating test cases, these three deserve special treatment and >> would continue to fail gracefully. >> >> Subsequently the --stack-trace-on-illegal can be deprecated as well, >> because its only purpose is to make the hidden asserts more verbose, which >> actual crashes at the check site would accomplish implicitly. >> >> Random data point: I have a permanent breakpoint on >> Isolate::ThrowIllegalOperation in my gdbinit file because I regularly >> wasted about 10 minutes tracking failures back to these asserts on several >> occasions already. >> >> Comments? Thoughts? >> >> Best regards, >> Michael >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
