Ok, I think there is a chance that generated code is the problem. Arm
and arm simulator behave the same, windows works fine.
StoreIC_Miss - in
IC::IC - in
handler befd28d0 - OK
IC::IC - out
StoreIC_Miss - out
IC::IC - in
handler befd28d0 - OK
IC::IC - out
IC::IC - in
handler befd28d0 - OK
IC::IC - out
IC::IC - in
handler befd28d0
IC::IC - out
StoreIC_Miss - in
IC::IC - in
handler 45ab0055 <--------------assert
thread.handler_ gets corrupted...
Advice is appreciated.
Thanks
Vlad
On Jul 28, 3:04 pm, vlad <[email protected]> wrote:
> Somehow recursiveness causes it...
> V8Proxy::callFunction -in
> Function::Call-1 - in
> execution::call - in
> Invoke - in
> Invoke - in
> Function::Call-1 - in
> execution::call - in
> execution::call - out
> Function::Call-1 - out
> Invoke - out
> handler be85c988
> handler 479e4055 ????
> #
> # Fatal error in src/frames.cpp, line 46
> # CHECK(frame->sp() <= handler->address()) failed
> #
>
> On Jul 28, 9:22 am, vlad vladbph <[email protected]> wrote:
>
>
>
> > Thank you Lasse. But in my case it is one thread. I'm running v8 using
> > webkit. It is just js invoked from index.html file. Any other reasons that
> > could cause that?
>
> > On Wed, Jul 28, 2010 at 12:31 AM, Lasse R.H. Nielsen
> > <[email protected]>wrote:
>
> > > The check failing means that your stack pointer is above the address of a
> > > stack-allocated handler - i.e., the handler is not on the stack.
> > > The most likely reason for this is that you are running V8 code from
> > > multiple threads, and the stack that the sp refer to isn't the same that
> > > the
> > > handler was allocated on.
> > > Only one thread may access V8 code at a time, and switching between
> > > threads
> > > should be done correctly to ensure that the thread-local state matches the
> > > thread that uses V8.
>
> > > /Lasse
>
> > > On Tue, Jul 27, 2010 at 23:36, vlad <[email protected]> wrote:
>
> > >> I debugged further - for some reasons thread_local_>handler_ gets
> > >> incorrect value so ASSERT(frame->sp() <= handler->address()) fails...
>
> > >> On Jul 26, 1:51 pm, vlad <[email protected]> wrote:
> > >> > I checked windows build and it works fine. Also checked if this is the
> > >> > same issue as Issue 122 in v8: GCC compiler bug in GCC 4.2.3 -
> > >> > msg#00606, but it is not. Tried -fno-strict-aliasing no help. :(
>
> > >> >http://code.google.com/p/v8/issues/detail?id=122
>
> > >> > Any advice what I can try? b/c it seems to be code generated for arm.
>
> > >> > Thanks
> > >> > Vlad
>
> > >> > On Jul 26, 10:14 am, vlad <[email protected]> wrote:
>
> > >> > > Hi,
> > >> > > I'm getting this error while running some of the JS code. What would
> > >> > > be potential cause for this check to fail?
>
> > >> > > StackHandlerIterator(const StackFrame* frame, StackHandler*
> > >> > > handler)
> > >> > > : limit_(frame->fp()), handler_(handler) {
>
> > >> > > // Make sure the handler has already been unwound to this frame.
> > >> > > ASSERT(frame->sp() <= handler->address()); <----------------
> > >> > > }
>
> > >> > > Could it be the case of running out of stack? If yes, is there any
> > >> > > way
> > >> > > to increase it?
>
> > >> > > Thanks
> > >> > > Vlad
>
> > >> --
> > >> v8-users mailing list
> > >> [email protected]
> > >>http://groups.google.com/group/v8-users
>
> > >> --
> > >> Lasse R.H. Nielsen / <http://groups.google.com/group/v8-users>
> > >> [email protected]
> > >> 'Faith without judgement merely degrades the spirit divine'
>
> > >> --
> > > v8-users mailing list
> > > [email protected]
> > >http://groups.google.com/group/v8-users
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
