crash [@ nsAttrAndChildArray::ChildCount]




13 years ago
8 years ago


(Reporter: moco, Assigned: graydon)



Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(crash signature)


(1 attachment, 1 obsolete attachment)

my trunk debug windows build is crashing at nsAttrAndChildArray::ChildCount()

-		this	0x054d3380 {mImpl=0xeaf3d473 }	const nsAttrAndChildArray * const
-		mImpl	0xeaf3d473 {mAttrAndChildCount=??? mBufferSize=??? mMappedAttrs=??? ...}	nsAttrAndChildArray::Impl *
		mAttrAndChildCount	CXX0030: Error: expression cannot be evaluated	
		mBufferSize	CXX0030: Error: expression cannot be evaluated	
		mMappedAttrs	CXX0030: Error: expression cannot be evaluated	
-		mBuffer	0xeaf3d47f	void * [1]
		[0]	CXX0030: Error: expression cannot be evaluated	

mImpl is garbage.

Here is the stack:

>	gklayout.dll!nsAttrAndChildArray::ChildCount()  Line 83 + 0xd bytes	C++
 	gklayout.dll!nsDocument::cycleCollection::Traverse(nsISupports * s=0x054d3278, nsCycleCollectionTraversalCallback & cb={...})  Line 823 + 0xe bytes	C++
 	xpcom_core.dll!nsCycleCollectionXPCOMRuntime::Traverse(void * p=0x054d3278, nsCycleCollectionTraversalCallback & cb={...})  Line 983 + 0x21 bytes	C++
 	xpcom_core.dll!GraphWalker::NoteXPCOMChild(nsISupports * child=0x054d3278)  Line 654	C++
 	gklayout.dll!nsEventListenerManager::cycleCollection::Traverse(nsISupports * s=0x050c7e50, nsCycleCollectionTraversalCallback & cb={...})  Line 418	C++
 	xpcom_core.dll!nsCycleCollectionXPCOMRuntime::Traverse(void * p=0x050c7e50, nsCycleCollectionTraversalCallback & cb={...})  Line 983 + 0x21 bytes	C++
 	xpcom_core.dll!GraphWalker::Walk(void * s0=0x055ab580)  Line 705 + 0x30 bytes	C++
 	xpcom_core.dll!nsCycleCollector::MarkRoots()  Line 762 + 0x21 bytes	C++
 	xpcom_core.dll!nsCycleCollector::Collect()  Line 1674	C++
 	xpcom_core.dll!nsCycleCollector_collect()  Line 1750	C++
 	xpcom_core.dll!nsEventQueue::GetEvent(int mayWait=0, nsIRunnable * * result=0x00000000)  Line 100	C++
 	xpcom_core.dll!nsThread::nsChainedEventQueue::GetEvent(int mayWait=0, nsIRunnable * * event=0x00000000)  Line 110	C++
 	xpcom_core.dll!nsThread::HasPendingEvents(int * result=0x0012fb40)  Line 456 + 0xf bytes	C++
 	xpcom_core.dll!NS_HasPendingEvents_P(nsIThread * thread=0x00badb38)  Line 205 + 0x12 bytes	C++
 	gkwidget.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x00badb38, int mayWait=1, unsigned int recursionDepth=0)  Line 238 + 0x10 bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fbc4)  Line 472	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00badb38, int mayWait=1)  Line 225 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 153 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 171 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00bab080, const nsXREAppData * aAppData=0x004036b4)  Line 2513 + 0x25 bytes	C++
 	firefox.exe!main(int argc=1, char * * argv=0x00bab080)  Line 61 + 0x13 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	nspr4.dll!_PR_MD_UNLOCK(_MDLock * lock=0x00000001)  Line 347	C
 	gklayout.dll!nsRuleNode::ComputeListData(nsStyleStruct * aStartStruct=, const nsCSSStruct & aData=, nsStyleContext * aContext=, nsRuleNode * aHighestNode=, const nsRuleNode::RuleDetail & aRuleDetail=, int aInherited=)  Line 3457 + 0x8 bytes	C++

more details coming...
No longer depends on: cycle-collector
I'm using my own build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070104 Minefield/3.0a2pre
I take that back, I have those tabs open, then I open a new tab (by clicking on a bugzilla link in email), and then it crashes.
actually, I have just thoes tabs open, and I'm readying one of them, and after a certain amount of time, I crash.
until there is a fix, graydon tells me I can run with XPCOM_CC_DO_NOTHING=1 in your environment.  (when I do that, I stop crashing)

but graydon warns not to run that long term, as it will leak memory pretty fast.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Blocks: 366127


13 years ago
Severity: normal → critical
Keywords: crash
Summary: [crash at nsAttrAndChildArray::ChildCount() → crash [@ nsAttrAndChildArray::ChildCount]

Comment 6

13 years ago
I've committed a slightly more real fix -- still a band-aid -- to the culprit class nsImageDocument. Can you confirm that the bug is suppressed by this? 

Tracking the long-term problem back over in bug 333078.
Posted patch what I was thinking (obsolete) — Splinter Review
This is what I was thinking of in bug 333078 comment 80, but I'm not sure how to test this.

Comment 8

13 years ago
I understand the approach you're suggesting now, and am willing to go that route. The patch you proposed almost does it, but misses a few other areas where canonicalization is necessary. 

This patch appears to handle it; to test, just open an nsImageDocument in one tab and then run TP2 with a few dozen iterations in another tab, to pump the event queue sufficiently. Make sure you run with XPCOM_CC_FAULT_IS_FATAL=1 and XPCOM_CC_REPORT_STATS=1 in your environment, to see that it's correctly collecting cycles all the way through the test.

Let me know if you like the look of this, and I'll commit it.
Assignee: nobody → graydon
Attachment #250854 - Attachment is obsolete: true
Attachment #250911 - Flags: review?


13 years ago
Attachment #250911 - Flags: review? → review?(dbaron)

Comment 9

13 years ago
I've committed this change, which should not change its observable status since it was "fixed" from a user-visible perspective with the previous band-aid. Now it's just fixed better. Reopen if you see it happen again.
Last Resolved: 13 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsAttrAndChildArray::ChildCount]
You need to log in before you can comment on or make changes to this bug.