I've actually been able to debug much deeper and have a better idea
what is going on.
A reminder, the function where the crash happens:
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;
}
Specifically on the >> marked line it's trying to look up the closure
from the current Context. Turns out that the current context is
pointing to some memory that has some random strings in it,
specifically the string "null" which translates to 0x6c6c756e. The
offset of the closure index for a Context is 7, and there we have the
consistent read violation address of 0x6c6c7575.
But... like I said before, it doesn't seem like it should have even
made it to that line of code, and I've just confirmed that. The
Bootstrapper::IsActive() function just above this code would have
returned false (I just checked in my debugger that
v8::internal::BootstrapperActive::nesting_ == 0). So, in debug, it
would have asserted.
So, backing up, global()->IsGlobalObject() should have returned true.
But it didn't. I was able to find the this pointer by checking
v8::internal::Top::thread_local_.context_. Then I found the offset to
the global index in the Context, which was 23*. At this position, I
found 0x00000004. I'm fairly sure that's not a global object, and I
would guess it's a memory overwrite, since it doesn't seem like a
Context would ever attempt to set 4 as a pointer to its GlobalObject.
I guess I'm just looking for a double-check of my reasoning. Given
what I found, it appears I should be trying to figure out what
overwrote the global of the top Context to be 4 instead of a valid
pointer. Does that make sense? Any ideas if this might be something
in V8 or if this might something that we've done? And any suggestions
on something I could do with V8 that would help track this down?
matt
* To be explicit in my math here:
23 = FixedArray::kHeaderSize + FixedArray::GLOBAL_INDEX * kPointerSize
- kHeapObjectTag
= FixedArray::kHeaderSize + 4*4 - 1
= HeapObject::kHeaderSize + kPointerSize + 4*4 - 1
= Object::kHeaderSize + kPointerSize + kPointerSize + 4*4 - 1
= 0 + 4 + 4 + 4*4 - 1
= 8 + 16 - 1
= 24 - 1
= 23
On Fri, Jun 4, 2010 at 10:01 AM, Matt Seegmiller <[email protected]> wrote:
> On Wed, Jun 2, 2010 at 3:51 AM, Erik Corry <[email protected]> wrote:
>> Den 1. jun. 2010 22.46 skrev Matt Seegmiller <[email protected]>:
>>>
>>> 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.
>
> That definitely is suspicious, and we've had it a couple more times
> with the same location. But I almost think it's a red herring. If I
> understand the code in contexts.cc near the crash, it shouldn't even
> be getting to that line unless V8 is bootstrapping, and this is well
> into our game running, so I would guess V8 is long past boostrapping
> (unless I don't understand when bootstrapping happens). So, it looks
> like some piece of state is incorrect such that
> global()->IsGlobalObject() is returning false when it should be
> returning true. Is that a correct analysis of the code there? Or is
> there something else going on? When would global()->IsGlobalObject()
> return false? When is the bootstrapper active?
>
> I'm independently trying to run with the verify-heap flag as
> suggested. I'll post if I get anything from that, but it seems like
> there could be some useful information gained from static analysis
> here.
>
> matt
>
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
