Closed Bug 649579 Opened 11 years ago Closed 11 years ago
Assertion failure: bit < Bit
Count, at js/src/jsgc .h:210 during cycle collection
1. tracemonkey only. I've only reproduced on Mac but have no reason to this it is really Mac only. 2. http://www.raaga.com/channels/tamil 3. Assertion failure: bit < BitCount, at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/js/src/jsgc.h:210 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 [Switching to process 53576 thread 0x2f03] 0x067923d3 in JS_Assert (s=0x6adeada "bit < BitCount", file=0x6a251e8 "/work/mozilla/builds/2.0.0-tracemonkey/mozilla/js/src/jsgc.h", ln=210) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/js/src/jsutil.cpp:86 86 *((int *) NULL) = 0; /* To continue from here in GDB: "return" then "continue". */ (gdb) bt #0 0x067923d3 in JS_Assert (s=0x6adeada "bit < BitCount", file=0x6a251e8 "/work/mozilla/builds/2.0.0-tracemonkey/mozilla/js/src/jsgc.h", ln=210) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/js/src/jsutil.cpp:86 #1 0x0667e0cc in js::gc::ArenaBitmap::isMarked (this=0x6dfdec0, bit=4294967294, color=1) at jsgc.h:210 #2 0x066829ce in js::gc::Cell::isMarked (this=0x6dbb000, color=1) at jsgc.h:478 #3 0x0666f8bd in js_GCThingIsMarked (thing=0x6dbb000, color=1) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/js/src/jsgc.cpp:523 #4 0x05a16cf1 in xpc_IsGrayGCThing (thing=0x6dbb000) at xpcpublic.h:153 #5 0x062165a8 in GCGraphBuilder::NoteScriptChild (this=0xb00a0d0c, langID=2, child=0x6dbb000) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/base/nsCycleCollector.cpp:1679 #6 0x06183ad6 in NoteChild (aLangID=2, aScriptThing=0x6dbb000, aClosure=0xb00a0d0c) at nsCycleCollectionParticipant.cpp:46 #7 0x05449ae5 in nsJSScriptTimeoutHandler::cycleCollection::Trace (this=0x6df4fac, p=0x23b62890, aCallback=0x6183aaa <NoteChild(unsigned int, void*, void*)>, aClosure=0xb00a0d0c) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/dom/base/nsJSTimeoutHandler.cpp:161 #8 0x06183b0f in nsScriptObjectTracer::TraverseScriptObjects (this=0x6df4fac, p=0x23b62890, cb=@0xb00a0d0c) at nsCycleCollectionParticipant.cpp:53 #9 0x05449f1f in nsJSScriptTimeoutHandler::cycleCollection::Traverse (this=0x6df4fac, p=0x23b62890, cb=@0xb00a0d0c) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/dom/base/nsJSTimeoutHandler.cpp:157 #10 0x06215c90 in GCGraphBuilder::Traverse (this=0xb00a0d0c, aPtrInfo=0x27318a9c) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/base/nsCycleCollector.cpp:1524 #11 0x06215d2e in nsCycleCollector::MarkRoots (this=0x80cc00, builder=@0xb00a0d0c) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/base/nsCycleCollector.cpp:1772 #12 0x06215edf in nsCycleCollector::BeginCollection (this=0x80cc00, aForceGC=0, aListener=0x0) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/base/nsCycleCollector.cpp:2641 #13 0x06218e21 in nsCycleCollectorRunner::Run (this=0x519f30) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/base/nsCycleCollector.cpp:3329 #14 0x061fb81c in nsThread::ProcessNextEvent (this=0x51a0e0, mayWait=1, result=0xb00a0edc) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/threads/nsThread.cpp:622 #15 0x0618324a in NS_ProcessNextEvent_P (thread=0x51a0e0, mayWait=1) at nsThreadUtils.cpp:250 #16 0x061fc1ef in nsThread::ThreadFunc (arg=0x51a0e0) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/xpcom/threads/nsThread.cpp:273 #17 0x00086ae9 in _pt_root (arg=0x51a3e0) at /work/mozilla/builds/2.0.0-tracemonkey/mozilla/nsprpub/pr/src/pthreads/ptthread.c:187 #18 0x91492155 in _pthread_start () #19 0x91492012 in thread_start () I've tried to reduce it but it naive attempts have still left non-local resources which make the reduction non-deterministic. If needed, I can work on it more, but perhaps you can figure out a test case easier than I can.
bit is supposed to be < 512, but is actually 4294967294. This is 2^32 - 2 (ie -1), and the value comes from cellIndex which is calculated like so: this->asFreeCell() - arena()->t.things.asFreeCell(); I'll look around some more. I don't have any theories why this would fail here but not elsewhere, as it looks like it may be ALMOST working...
It looks like this cycle collection is being run off the main thread. The original use of xpc_IsGrayGCThing in nsXPConnect.cpp is only called if markJSObject is false. markJSObject seems to be true if the class is not an XPC_WN_Tearoff_JSClass, the object is a wrapper, WrapperIsNotMainThreadOnly is true for the wrapper, and the wrapper has external references. Maybe if all of those conditions hold, and we're off the main thread, then the GC map is in some kind of bogus state that causes this failure of xpc_IsGrayGCThing? This change is in bug 641910, and is also on Mozilla Central and Aurora.
This looks very similar to this crash signature: https://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=js_GCThingIsMarked%28void*%2C%20unsigned%20int%29&version=Firefox%3A4.2a1pre These look like they are all instances of a thread thing firing up a CC, then either GCGraphBuilder::NoteScriptChild (as in the crash report above) or NoteJSChild (occasionally) invoke js_GCThingIsMarked, which causes a crash. I don't think NoteJSChild is something that my patch affected. It looks like that instance of js_GCThingIsMarked was added in Bug 614347. That said, I don't see any crashes in js_GCThingIsMarked in 4.0 on crash-stats.
What version were you using? I tried the URL you gave with the tinderbox build tracemonkey-macosx64-debug/1302712554/ and the page loaded just fine, and didn't generate the given assertion in the NSPR log. I don't have Flash installed, which could also be a factor.
http://hg.mozilla.org/tracemonkey/rev/4ace629bb676 I'll pull/build again and check. I'm on 32bit Mac OS X 10.5 fwiw.
I can't reproduce either with the url or the partial saved test cases. Lots of changes since Saturday but nothing that stands out to me. I'll mark it WFM for now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Marking as a duplicate of Bug 650519, because the call stack in the initial post looks like those that are showing up in that bug.
Resolution: WORKSFORME → DUPLICATE
Duplicate of bug: 650519
You need to log in before you can comment on or make changes to this bug.