Closed Bug 647467 Opened 13 years ago Closed 13 years ago

AssertValidColor failed with setTimeout, CC


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
firefox5 + fixed
firefox6 + fixed
status2.0 --- unaffected
status1.9.2 --- unaffected
blocking-fx --- ?
status1.9.1 --- unaffected


(Reporter: jruderman, Assigned: paul.biggar)


(Keywords: assertion, regression, testcase, Whiteboard: [sg:dupe 650519])


(2 files)

1. Install 'DOM Fuzz Lite' from
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
blocking-fx: --- → ?
Can't reproduce on a local build, or one downloaded for that changeset ( 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. (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.
Assignee: general → pbiggar
This is reproducible with a local build, by following the same steps as tinderbox ( 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 , , 

Assertion failure: color < aheader->getThingSize() / Cell::CellSize

and a crash at

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.
OS: Linux → All
Hardware: x86_64 → All
CCing Andrew McCreight, who helped investigate bug 649579.
What does the call stack look like?  If it looks like either of these:

...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.
OS: All → Linux
Hardware: All → x86_64
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.)
OS: Linux → All
Hardware: x86_64 → All
Confirmed dup.

Works in revision, but not in its parent.
Closed: 13 years ago
Resolution: --- → DUPLICATE
Group: core-security
Keywords: regression
Whiteboard: [sg:dupe 650519]
You need to log in before you can comment on or make changes to this bug.