366063 - crash [@ nsAttrAndChildArray::ChildCount]

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[(not reading, please use [e-mail] instead)]

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

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsAttrAndChildArray.h#83

-		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
 	kernel32.dll!7c816fd7() 	
 	[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...

Comment 1

[(not reading, please use [e-mail] instead)]

I've got these tabs open:

http://foobarcheese.blogspot.com/
https://intranet.mozilla.org/images/2/2e/Sicore.jpg
http://www.google.com/search?q=Sicore%2C+Damon&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:unofficial&client=firefox-a
http://damon.sicore.org/
http://72.14.253.104/search?q=cache:JaZh1Bi2rj0J:damon.sicore.org/resume/damon.pdf+Sicore,+Damon&hl=en&gl=us&ct=clnk&cd=2&client=firefox-a
http://labs.jboss.org/portal/jbosslabs
about:blank
https://bugzilla.mozilla.org/show_bug.cgi?id=364599
https://bugzilla.mozilla.org/show_bug.cgi?id=333078

it seems like if I just wait a minute or two, the browser will crash.

Comment 2

[(not reading, please use [e-mail] instead)]

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

Comment 3

[(not reading, please use [e-mail] instead)]

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.

Comment 4

[(not reading, please use [e-mail] instead)]

actually, I have just thoes tabs open, and I'm readying one of them, and after a certain amount of time, I crash.

Comment 5

[(not reading, please use [e-mail] instead)]

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.

Comment 6

[Graydon Hoare :graydon]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: what I was thinking

This is what I was thinking of in bug 333078 comment 80, but I'm not sure how to test this.

Comment 8

[Graydon Hoare :graydon]

Attachment: corrected variant of dbaron's proposal

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.

Comment 9

[Graydon Hoare :graydon]

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.