Last Comment Bug 647467 - AssertValidColor failed with setTimeout, CC
: AssertValidColor failed with setTimeout, CC
Status: RESOLVED DUPLICATE of bug 650519
[sg:dupe 650519]
: assertion, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
-- critical (vote)
: ---
Assigned To: Paul Biggar
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 326633 532972
  Show dependency treegraph
Reported: 2011-04-02 11:58 PDT by Jesse Ruderman
Modified: 2011-06-09 15:12 PDT (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (requires extension for CC) (crashes when loaded) (158 bytes, text/html)
2011-04-02 11:58 PDT, Jesse Ruderman
no flags Details
crash report (mac debug) (40.08 KB, text/plain)
2011-05-08 15:29 PDT, Jesse Ruderman
no flags Details

Description User image Jesse Ruderman 2011-04-02 11:58:54 PDT
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 User image Jesse Ruderman 2011-04-02 12:34:38 PDT
I can reproduce with a build from Tinderbox, but not with a local build!? All linux64-debug, all built from
Comment 2 User image Paul Biggar 2011-05-04 08:07:46 PDT
Can't reproduce on a local build, or one downloaded for that changeset ( on OSX 64 debug. Bringing out virtualbox...
Comment 3 User image Paul Biggar 2011-05-04 08:48:26 PDT
Can't reproduce on linux 32bit either. installing a 64 bit image...
Comment 4 User image Jesse Ruderman 2011-05-04 20:08:19 PDT
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 User image Paul Biggar 2011-05-05 04:33:36 PDT
OK, I can reproduce with the Mac build - thanks.
Comment 6 User image Paul Biggar 2011-05-05 07:53:04 PDT
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 User image Jesse Ruderman 2011-05-06 21:36:42 PDT
[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.
Comment 8 User image Bob Clary [:bc:] 2011-05-08 05:38:38 PDT
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.
Comment 9 User image Jesse Ruderman 2011-05-08 12:48:33 PDT
CCing Andrew McCreight, who helped investigate bug 649579.
Comment 10 User image Andrew McCreight [:mccr8] 2011-05-08 13:21:09 PDT
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 User image Jesse Ruderman 2011-05-08 15:29:28 PDT
Created attachment 530955 [details]
crash report (mac debug)

I see nsJSScriptTimeoutHandler::cycleCollection::Trace in the stack, but not nsJSArgArray::cycleCollection::Trace.
Comment 12 User image Andrew McCreight [:mccr8] 2011-05-08 20:17:04 PDT
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 User image Paul Biggar 2011-05-09 04:33:07 PDT
OK, will check a recent TM build.
Comment 14 User image Bob Clary [:bc:] 2011-05-09 04:43:26 PDT
Paul, this also occurs on 32 bit builds in Windows. It is not just 64 bit Linux.
Comment 15 User image Paul Biggar 2011-05-09 05:08:02 PDT
> 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.)
Comment 16 User image Paul Biggar 2011-05-09 07:11:08 PDT
Confirmed dup.

Works in revision, but not in its parent.

*** This bug has been marked as a duplicate of bug 650519 ***

Note You need to log in before you can comment on or make changes to this bug.