Hi Matt, So if I am reading you correctly crashes started after you switched to r4756, I am right?
If it is possible try running your application with debug version of V8 and verify-heap flag enabled. -- Vyacheslav Egorov On Tue, Jun 1, 2010 at 10:46 PM, Matt Seegmiller <[email protected]> wrote: > 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 > 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
