647467 - AssertValidColor failed with setTimeout, CC

Status: RESOLVED DUPLICATE of bug 650519

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: testcase (requires extension for CC) (crashes when loaded)

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.

Comment 1

[Jesse Ruderman]

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

Comment 2

[Paul Biggar]

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...

Comment 3

[Paul Biggar]

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

Comment 4

[Jesse Ruderman]

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

Comment 5

[Paul Biggar]

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

Comment 6

[Paul Biggar]

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.)

Comment 7

[Jesse Ruderman]

[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

[Bob Clary [:bc] (inactive)]

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.

Comment 9

[Jesse Ruderman]

CCing Andrew McCreight, who helped investigate bug 649579.

Comment 10

[Andrew McCreight [:mccr8]]

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.

Comment 11

[Jesse Ruderman]

Attachment: crash report (mac debug)

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

Comment 12

[Andrew McCreight [:mccr8]]

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

[Paul Biggar]

OK, will check a recent TM build.

Comment 14

[Bob Clary [:bc] (inactive)]

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

Comment 15

[Paul Biggar]

> 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

[Paul Biggar]

Confirmed dup.

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