Wow thanks for the super quick fix on this, Vyacheslav! On Wed, Oct 12, 2011 at 2:25 AM, Vyacheslav Egorov <[email protected]>wrote:
> > Would this be a valuable bug report as is? > > Yes, please file a bug with a repro so we can start looking. > > -- > Vyacheslav Egorov > > > On Wed, Oct 12, 2011 at 2:25 AM, Marcel Laverdet <[email protected]> > wrote: > > I've managed to simplify the repro case a lot, removing the dependency on > > NodeJS and other externalities. The error should reproduce easily enough > on > > other Lion computers, at least. It still requires the node-fibers library > > because the pthread invocations that are happening are difficult to > > detangle. > > Would this be a valuable bug report as is? I'm at a loss at this point. > > Also in addition to the failed assertion in the first message, sometimes > I'm > > getting this: > > # > > # Fatal error in src/objects-inl.h, line 1652 > > # CHECK(index >= 0 && index < this->length()) failed > > # > > On Tue, Oct 11, 2011 at 3:30 PM, Vyacheslav Egorov <[email protected] > > > > wrote: > >> > >> Marcel, > >> > >> It's really hard to say anything without reproduction. It might be a > >> genuine bug in the deoptimizer. > >> > >> -- > >> Vyacheslav Egorov > >> > >> > >> > >> On Tue, Oct 11, 2011 at 9:53 PM, Marcel Laverdet <[email protected]> > >> wrote: > >> > Hey there I'm trying to track down an issue with my v8 application (on > >> > NodeJS). This is on OS X Lion and x64 v8. I've noticed this error on > v8 > >> > 3.6.6 and also bleeding_edge. > >> > The issue is that every now and then I'm seeing this: > >> > [couldn't find pc offset for node=0] > >> > [method: Future.wait] > >> > [source: > >> > function () {???Future.wait(this);???return this.get();??} > >> > Bus error: 10 > >> > This error seems to come from deoptimizer.cc and reproducing the error > >> > is > >> > difficult. The only thing strange about my application is that I'm > using > >> > node-fibers [https://github.com/laverdet/node-fibers], which adds > >> > coroutine > >> > support to v8. Each coroutine is actually just a pthread and > >> > pthread_cond_signal is used to simulate coroutines** which play nicely > >> > with > >> > v8::Locker. So it seems that this issue may be related to threads, > >> > potentially 100's of threads using the same v8 isolate (locking and > >> > unlocking where appropriate). > >> > If I run this instead with a debug build of v8 I get this error: > >> > # > >> > # Fatal error in /Users/marcel/code/node/deps/v8/src/objects-inl.h, > line > >> > 2996 > >> > # CHECK(kind() == OPTIMIZED_FUNCTION) failed > >> > # > >> > I have NOT been able to reproduce this problem on an ia32 build with > the > >> > same application and machine; it seems to be just x64. > >> > I'm wondering where I should start looking from here. Is this a bug in > >> > v8, > >> > should I work on distilling a test case for you guys? > >> > ** Actually the default version of node-fibers uses some not-supported > >> > v8 > >> > hacking to get true coroutines, but you can modify the build to use > >> > pthreads > >> > instead which is totally within the confines of v8's API. All my > testing > >> > was > >> > done with the pthread_cond_signal version of node-fibers. > >> > > >> > -- > >> > 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 > > > > -- > > 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 > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
