> 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 <mar...@laverdet.com> 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 <vego...@chromium.org>
> 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 <mar...@laverdet.com>
>> 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
>> > v8-users@googlegroups.com
>> > http://groups.google.com/group/v8-users
>>
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
