Jesse Ruderman Reporter
	Description • 18 years ago

This testcase causes a crash due to too much recursion after a few seconds.  Here's part of the stack trace (Mac debug, gdb):

#11499 0x06a7df48 in nsHTMLInputElement::BindToTree (this=0x2816a7e0, aDocument=0x0, aParent=0x28169650, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsHTMLInputElement.cpp:1778
#11500 0x069b2a64 in nsGenericElement::BindToTree (this=0x28169650, aDocument=0x0, aParent=0x28165900, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/base/src/nsGenericElement.cpp:1834
#11501 0x06a52440 in nsGenericHTMLElement::BindToTree (this=0x28169650, aDocument=0x0, aParent=0x28165900, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:1358
#11502 0x069b2a64 in nsGenericElement::BindToTree (this=0x28165900, aDocument=0x0, aParent=0x2816a7e0, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/base/src/nsGenericElement.cpp:1834
#11503 0x06a52440 in nsGenericHTMLElement::BindToTree (this=0x28165900, aDocument=0x0, aParent=0x2816a7e0, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:1358
#11504 0x069b2a64 in nsGenericElement::BindToTree (this=0x2816a7e0, aDocument=0x0, aParent=0x28169650, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/base/src/nsGenericElement.cpp:1834
#11505 0x06a52440 in nsGenericHTMLElement::BindToTree (this=0x2816a7e0, aDocument=0x0, aParent=0x28169650, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:1358
#11506 0x06a54c3c in nsGenericHTMLFormElement::BindToTree (this=0x2816a7e0, aDocument=0x0, aParent=0x28169650, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:3112
#11507 0x06a7df48 in nsHTMLInputElement::BindToTree (this=0x2816a7e0, aDocument=0x0, aParent=0x28169650, aBindingParent=0x0, aCompileEventHandlers=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsHTMLInputElement.cpp:1778

	Tobias Fischer
	Comment 2 • 18 years ago

Humm, seems to be not MacOS X specific. The Testcase crashes SeaMonkey Trunk Build 2006111909 on Windows too: TB26229429G, TB26229391K

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 3 • 18 years ago

(In reply to comment #2)
> Humm, seems to be not MacOS X specific. The Testcase crashes SeaMonkey Trunk
> Build 2006111909 on Windows too: TB26229429G, TB26229391K

Looks like a different stack trace for SM:

Stack Signature	 nsAttrAndChildArray::GetAttr a1eb15b2
Product ID	MozillaTrunk
Build ID	2006111909
Trigger Time	2006-11-19 13:50:38.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	gklayout.dll + (001037eb)
URL visited	
User Comments	
Since Last Crash	367 sec
Total Uptime	6643 sec
Trigger Reason	Stack overflow
Source File, Line No.	d:\builds\tinderbox\seamonkeytrunk\winnt_5.2_clobber\mozilla\content\base\src\nsattrandchildarray.cpp, line 303
Stack Trace 	
nsAttrAndChildArray::GetAttr  [mozilla\content\base\src\nsattrandchildarray.cpp, line 303]
nsGenericHTMLElement::ReparseStyleAttribute  [mozilla\content\html\content\src\nsgenerichtmlelement.cpp, line 2380]

Really seems to be trunk related. No crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0 after waiting over a minute.

	Jesse Ruderman Reporter
	Comment 4 • 18 years ago

> Looks like a different stack trace for SM:
> ...
> Trigger Reason  Stack overflow

For any given stack overflow bug, you can get crashes with several different functions at the *top* of the stack.  You have to look at the *middle* of the stack -- the part that repeats -- to determine whether it's the same functions going through infinite- or too-much-recursion.

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 18 years ago

Yeah, so this is another manifestation of the problem where destroying a document partly but not completely removes nodes from its childlist.  The call to 

  try { aC(document.body, iframe);    } catch(e) { }

blows away the old document in the iframe, so the call to 

  try { aC(div, iframeDocElem);       } catch(e) { }

doesn't remove the node from the iframe document's child list.  Then at some point that document gets GCed and the parent of the iframeDocElem suddenly gets nulled out again.  The next call to 

  try { aC(textbox, div); } catch(e) { }

doesn't detect a loop (since the parent of the iframeDocElem is null, while the iframeDocElem is actually a child of the div).  So we end up with a loop in the content tree and then the recursion crash observed.

We really need to fix bug 348156.

	Damon Sicore (:damons)
	Comment 6 • 17 years ago

This needs to be resolved in order to find other security issues via fuzz testing per discussion in Security triage.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 7 • 17 years ago

Sorry, wasn't going to take this (yet)

	Jonas Sicking (:sicking) No longer reading bugmail consistently Assignee
	Comment 8 • 17 years ago

Taking this since it'll get fixed with my fix for bug 348156

	Jonas Sicking (:sicking) No longer reading bugmail consistently Assignee
	Comment 9 • 17 years ago

Should be fixed by patch in bug 348156

	Carsten Book [:Tomcat]
	Comment 10 • 17 years ago

no crash with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre)
Gecko/2008020717 Firefox/3.0b4pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 on the testcase

-> Verified fixed