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

Would this also affect the illegal access exceptions you get when you
call e.g. Debug.scripts() before Debug.setListener()?  If it does,
that's arguably not a great user experience for embedders.

-- 
-- 
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.

Reply via email to