Closed Bug 395562 Opened 13 years ago Closed 12 years ago

Cycle collector faults followed by crash running the given set of mochitests

Categories

(Core :: DOM: Core & HTML, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 386912

People

(Reporter: Waldo, Unassigned)

References

Details

(Keywords: assertion, crash)

Attachments

(1 file)

Attached file Zipped mochitest set
I consistently get some assertions, cycle collector faults, and a crash doing the following:

1. Uncomment the DEBUG_CC defines in the two relevant places.
2. This might not be necessary, but if for no other reason than to
   save time, comment out |MaybeDrawGraphs(graph);| in
   nsCycleCollector::Collect, both the one after |ScanRoots(graph);|
   and the one at the end of the function.
3. make -f client.mk
4. Copy the small/ folder out of the attached zip file into
   $OBJDIR/_tests/testing/mochitest/tests.
5. From $OBJDIR/_tests/testing/mochitest:

   $ perl runtests.pl --autorun --close-when-done --test-path=small

The crash is in EdgePool::Iterator::operator *, with both |mPointer| and |(mPointer + 1)| having null |ptrInfo| and |block| members.  I get the following in the console spew:

###!!! ASSERTION: JS object but unknown to the JS GC?: 'mObjRefcounts->Get(p) > 0', file c:/moz/trunk/mozilla/js/src/xpconnect/src/nsXPConnect.cpp, line 611
###!!! ASSERTION: JS object but unknown to the JS GC?: 'refcount > 0', file c:/moz/trunk/mozilla/js/src/xpconnect/src/nsXPConnect.cpp, line 717
Fault in cycle collector: zero refcount
  while operating on pointer 00DB63E0 JS Object (Function)
  which has internal references from:
    057A63D0 nsJSScriptTimeoutHandler

The stack at time of crash is as follows:

xpcom_core!EdgePool::Iterator::operator*(void)+0x19
xpcom_core!Fault(char * msg = 0x003872b0 "zero refcount", struct PtrInfo * pi = 0x066582c4)+0xad
xpcom_core!GCGraphBuilder::DescribeNode(unsigned long refCount = 0, unsigned int objSz = 0x20, char * objName = 0x0012f794 "JS Object (Function)")+0x3b
xpc3250!nsXPConnect::Traverse(void * p = 0x00db63e0, class nsCycleCollectionTraversalCallback * cb = 0x0012f864)+0x3d0
xpcom_core!GCGraphBuilder::Traverse(struct PtrInfo * aPtrInfo = 0x066582c4)+0x68
xpcom_core!nsCycleCollector::MarkRoots(struct GCGraph * graph = 0x0012f8f0)+0xee
xpcom_core!nsCycleCollector::Collect(unsigned int aTryCollections = 1)+0x150
xpcom_core!nsCycleCollector_collect(void)+0x19
gklayout!nsJSContext::Notify(class nsITimer * timer = 0x0489ce78)+0x7d
xpcom_core!nsTimerImpl::Fire(void)+0x250
xpcom_core!nsTimerEvent::Run(void)+0xa1
xpcom_core!nsThread::ProcessNextEvent(int mayWait = 1, int * result = 0x0012f9e8)+0x1fa

This might be a recent regression; I've been attacking this set of tests for the last week or two to try and get rid of the two leaked windows in Mochitests, and I don't think it was crashing as of sometime early this week.  (I've been a little sloppy in getting a minimal set of Mochitests to debug the leak, and the leaking of the windows is a tad non-deterministic, so it might just be that the sets I'd been trying didn't trigger whatever happens here.)

Based purely on the last line of cycle collector fault output, I'm filing this as a DOM0 bug; it may easily be something else entirely.

I poked a bit at the JS Object mentioned in the fault (only once, and only just now, so no guarantees this logic holds every time I hit this crash).  The function is in browser.js somewhere, based on fun.u.i.script, and lineno == 3116.  flags == 0x8008, so it's an anonymous interpreted function.  Its atomMap contains three atoms; the first is "gProgressMeterPanel" and the second is "collapsed", so I think it's pretty clear we're looking at the following function, and that the lineno was just way off (broken?) or I'm misinterpreting it:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/base/content/browser.js&rev=1.841&mark=3416-3419#3414

I'm not sure where else to go from here, so I'm going to leave it at this.  I have this in a VM right now, so if there's anything else you might want to me to poke right now, in the crashed state, let me know soon-ish in case I have a need for the disk space.
Blocks: 386912
Peter/Jst/Sicking is this something we need to jump on for b1?
This should be fixed by the patch for bug 401687 and looks like a dupe of bug 386912.
Jeff, do you see any faults with a recent nightly?

If we still see faults I would say this is a beta blocker yes. At least until we've figured out what's going wrong.
Jeff - can you re-test asap so we can figure of if there is more to investigate here?
Flags: blocking1.9?
I'll give this another go after my last final, which ends at 4:30 next Thursday.
I can't reproduce this any more!  Marking as a dup of bug 386912, since I don't see how it could be anything else...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 386912
You need to log in before you can comment on or make changes to this bug.