Note: There are a few cases of duplicates in user autocompletion which are being worked on.

AssertValidColor failed with setTimeout, CC




JavaScript Engine
6 years ago
6 years ago


(Reporter: Jesse Ruderman, Assigned: Paul Biggar)


(Blocks: 2 bugs, {assertion, regression, testcase})

assertion, regression, testcase
Dependency tree / graph

Firefox Tracking Flags

(firefox5+ fixed, firefox6+ fixed, status2.0 unaffected, status1.9.2 unaffected, blocking-fx ?, status1.9.1 unaffected)


(Whiteboard: [sg:dupe 650519])


(2 attachments)



6 years ago
Created attachment 523803 [details]
testcase (requires extension for CC) (crashes when loaded)

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.

Comment 1

6 years ago
I can reproduce with a build from Tinderbox, but not with a local build!? All linux64-debug, all built from


6 years ago
blocking-fx: --- → ?

Comment 2

6 years ago
Can't reproduce on a local build, or one downloaded for that changeset ( on OSX 64 debug. Bringing out virtualbox...

Comment 3

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

Comment 4

6 years ago
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

Comment 5

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


6 years ago
Assignee: general → pbiggar

Comment 6

6 years ago
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.)

Comment 7

6 years ago
[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.
tracking-firefox6: --- → ?

Comment 8

6 years ago
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.
Blocks: 532972
OS: Linux → All
Hardware: x86_64 → All

Comment 9

6 years ago
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.

Comment 11

6 years ago
Created attachment 530955 [details]
crash report (mac debug)

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.

Comment 13

6 years ago
OK, will check a recent TM build.
tracking-firefox6: ? → ---
OS: All → Linux
Hardware: All → x86_64

Comment 14

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

Comment 15

6 years ago
> 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.)
tracking-firefox6: --- → ?
OS: Linux → All
Hardware: x86_64 → All

Comment 16

6 years ago
Confirmed dup.

Works in revision, but not in its parent.
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 650519
Group: core-security
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
status2.0: --- → unaffected
status-firefox5: --- → fixed
status-firefox6: --- → fixed
tracking-firefox5: --- → +
tracking-firefox6: ? → +
Keywords: regression
Whiteboard: [sg:dupe 650519]
You need to log in before you can comment on or make changes to this bug.