On 2015/11/25 01:44:58, Yang wrote:
On 2015/11/25 01:41:13, Yang wrote:
> On 2015/11/25 00:04:51, caitp wrote:
> > On 2015/11/24 21:37:29, caitp wrote:
> > > +yang, do you have an idea what would cause the DCHECK failure in
> > > VerifyRecompiledCode()? It doesn't seem to break the code when
DCHECKS
are
> > > disabled.
> >
> > More context, old_target->kind() == BUILTIN, while new_target->kind()
==
STUB
>
> Caitlin,
>
> this check makes sure that when we recompile code for debugging (to get
code
> with debug break slots), the new code is in sync with the old one so
that we
can
> find the matching pc when replacing old code while it is on the stack.
We
match
> up positions in both code objects by counting calls up to the current
pc.
> Therefore we expect each call to correspond to each other.
>
> If you are not doing weird tricks like patching call targets after
compile,
the
> corresponding call (i.e. same number of calls preceding it) should not
target
> different code kinds.
>
> Let me know if you found anything. I can try to figure this one out in
the
> morning if you havent yet.
Btw this likely happens because the recompile took a different code path.
That
could be because of lazy vs eager parsing, because of debugger being
active,
or
maybe because of subtle inderminism in the parser/compiler.
DCHECK failure resolved, although it still doesn't make a ton of sense to
me why
(related to parameter initializer scopes not being rewritten, consistently)
https://codereview.chromium.org/1309813007/
--
--
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.
