Den 1. jun. 2010 22.46 skrev Matt Seegmiller <[email protected]>:
> We've been getting a crash in V8 sporadically and I was curious if
> there is someone who might know something obvious we're doing to cause
> it, or if this might be a bug, or anything helpful.
>
> I've posted before about using V8 in a multithreaded game engine.
> This is the same engine. This could very well be a multithreading
> issue we've introduced ourselves, or a completely
> non-threading-related issue, or a V8 bug, but because the crash is
> happening in V8, I'm not at all sure what might be the root cause.
>
> We're running on Windows 7, using VS2008 to build both V8 and our
> engine. We're currently using V8 trunk r4756 (2.2.13).
>
> The crash happens in contexts.cc line 61 or 62:
>
> Context* Context::global_context() {
> // Fast case: the global object for this context has been set. In
> // that case, the global object has a direct pointer to the global
> // context.
> if (global()->IsGlobalObject()) {
> return global()->global_context();
> }
>
> // During bootstrapping, the global object might not be set and we
> // have to search the context chain to find the global context.
> ASSERT(Bootstrapper::IsActive());
> Context* current = this;
> while (!current->IsGlobalContext()) {
> >> JSFunction* closure = JSFunction::cast(current->closure());
> >> current = Context::cast(closure->context());
> }
> return current;
> }
>
> From looking at the disassembly, it appears it's the
> current->closure() that is the specific crash. The crash is an Access
> Violation reading location 0x6c6c7575 (in the one case I wrote out, I
>
I don't have an idea for the crash. That is a suspiciously regular bit
pattern though. I ends in binary 01 so it could be a heap object pointer,
but it could also be part of a 16 bit RGB colour or the string "uull". So
what I'm saying is it looks a bit like a stray write from a different part
of the program.
> think it changes every time). So current is pointing to something
> non-NULL, but apparently bad. If I understand this code correctly,
> these lines shouldn't be executed except during bootstrapping, and I'm
> pretty sure this isn't during boostrapping.
>
> The call stack at the time of the crash is:
>
> > v8.dll!v8::internal::Context::global_context() Line 62 C++
>
>
> v8.dll!v8::internal::GetKeysInFixedArrayFor(v8::internal::Handle<v8::internal::JSObject>
> object={...}, v8::internal::KeyCollectionType type=INCLUDE_PROTOS)
> Line 595 + 0x19 bytes C++
> v8.dll!v8::Object::GetPropertyNames() Line 2152 C++
> locust-mljavascript-2_1.dll!CLVV8Array::GetSizeImpl() Line 108 +
> 0x13 bytes C++
>
> where locust-mljavascript-2_1.dll is the entry point from our code.
>
> At this point, this thread seems to have the lock on the V8 Locker,
> and there is another thread running that has always been waiting for
> the lock to be given up at the time of the crash.
>
> So, any ideas? Unfortunately, this is happening consistently but
> sporadically. We don't have a repeatable test case for it.
>
> Thanks,
>
> matt
>
> --
> 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
