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
