1. Install 'DOM Fuzz Lite' from https://www.squarefree.com/extensions/domFuzzLite.xpi 2. Load the testcase. Assertion failure: color < reinterpret_cast<const js::gc::FreeCell *>(thing)->arena()->header()->thingSize / sizeof(FreeCell), at js/src/jsgc.h:471 I think this is a regression from within the last 2 days. The patch in bug 634155 touched jsgc.h, so it's one possible cause.

I can reproduce with a build from Tinderbox, but not with a local build!? All linux64-debug, all built from http://hg.mozilla.org/mozilla-central/rev/4e4c7457e8f7

Can't reproduce on a local build, or one downloaded for that changeset (https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-04-03-03-mozilla-central-debug/) on OSX 64 debug. Bringing out virtualbox...

Can't reproduce on linux 32bit either. installing a 64 bit image...

Same situation on Mac: I can reproduce with a Tinderbox build, but not with a local build. https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1304558126/ (build for mozilla-central changeset ecfeced36f14). Assertion failure: color < aheader->getThingSize() / Cell::CellSize, at js/src/jsgc.h:485

OK, I can reproduce with the Mac build - thanks.

This is reproducible with a local build, by following the same steps as tinderbox (https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1304558126/mozilla-central-macosx64-debug-build3196.txt.gz) including their mozconfig, up to `make package`. (For some reason that build is hideously slow though, which the downloaded build isn't.)

[Nominating for tracking-firefox6.] I imagine this could cause "random GC-related crashes" in opt builds, and I keep discovering possible variants in debug builds.

Note also bug 649579 On 32 bit WinXP, and 32 builtd on 64 bit Win7 I've seen: at http://www.raaga.com/channels/hindi/ , http://www.raaga.com/channels/tamil/ , Assertion failure: color < aheader->getThingSize() / Cell::CellSize and a crash at Crash reason: EXCEPTION_ACCESS_VIOLATION_READ Crash address: 0x7ac2804 Thread 3 (crashed) 0 mozjs.dll!js::gc::ArenaHeader::getThingSize() [jsgc.cpp : 173 + 0x8] eip = 0x03a0494f esp = 0x0494fc48 ebp = 0x0494fc4c ebx = 0x0091fb30 esi = 0x00200000 edi = 0x00000000 eax = 0x03d9e010 ecx = 0x03d9e000 edx = 0x03d9efa8 efl = 0x00010202 Found by: given as instruction pointer in context 1 mozjs.dll!js::gc::AssertValidColor [jsgc.h : 485 + 0xd] eip = 0x03a0524d esp = 0x0494fc54 ebp = 0x0494fc58 Found by: call frame info 2 mozjs.dll!js_GCThingIsMarked(void *,unsigned int) [jsgc.cpp : 563 + 0xc] eip = 0x03a0543f esp = 0x0494fc60 ebp = 0x0494fc68 Found by: call frame info 3 xul.dll!xpc_IsGrayGCThing(void *) [xpcpublic.h : 153 + 0xb] eip = 0x01118b9f esp = 0x0494fc70 ebp = 0x0494fc78 Found by: call frame info ted: the breakpad exploitability tool flagged these as "low" exploitaibility.

CCing Andrew McCreight, who helped investigate bug 649579.

What does the call stack look like? If it looks like either of these: https://crash-stats.mozilla.com/report/index/9ae74b4c-ee10-46a7-b86b-caab02110508 https://crash-stats.mozilla.com/report/index/741e5400-0a05-4829-ae5b-663c32110507 ...then it is probably an instance of Bug 650519. The notable features to look for are nsJSArgArray::cycleCollection::Trace and nsJSScriptTimeoutHandler::cycleCollection::Trace. The problem there appears to be that xpc_IsGrayGCThing crashes when it is passed statically allocated JS strings. In a debug build, I could imagine that showing up as a AssertValidColor failure.

I see nsJSScriptTimeoutHandler::cycleCollection::Trace in the stack, but not nsJSArgArray::cycleCollection::Trace.

Yeah, it will just be one or the other. Basically, those two objects tend to shove JS strings into the cycle collector, which because of the code I added causes a crash. So I'd say this is a duplicate of Bug 650519. It doesn't seem like it should be much of a security problem. It seems like it is just going to read from part of statically allocated data. It is good to have a test case for it, though. I'll have to see if my patch actually works. It has been applied to Tracemonkey if you want to see if that matters.

OK, will check a recent TM build.

Paul, this also occurs on 32 bit builds in Windows. It is not just 64 bit Linux.

> tracking-firefox6: ? ⇒ ---Hardware: All ⇒ x86_64OS: All ⇒ Linux That was not at all intended. (I think I've finally understood why this keeps happening to me though. I have the page open, and the field are set. Then someone changes them. Then I refresh, keeping the old settings. Then I comment, accidentally changing the values.)

Confirmed dup. Works in revision http://hg.mozilla.org/tracemonkey/rev/624c69edea94, but not in its parent.