294235 - [FIXr]http://www.powweb.com/ crashes Firefox [@ nsHTMLDocument::MatchLinks]

Status: RESOLVED FIXED

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

Description

[Mike Pesce (:By-Tor)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050515 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050515 Firefox/1.0+

On loading http://www.powweb.com/ Firefox seems to get stuck halfway through
loading the page.  Either it just hangs or completely crashes.  

Reference conversation on Mozillazine:
http://forums.mozillazine.org/viewtopic.php?t=265680

Reproducible: Always

Steps to Reproduce:
1. Type www.powweb.com in location bar
2. Wait for it to load
3.

Actual Results:  
Firefox crashes

Expected Results:  
Page should load normally or catch error.

Comment 1

[José Jeria]

Talkback id: TB5846058Q

Comment 2

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050514
Firefox/1.0+ ID:2005051402 
Crashes for me - TB5827221H

Doesn't crash for me in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.8) Gecko/20050509 Firefox/1.0.4

When I save the webpage to HD using FF1.04 and then load it into FF-trunk the
page loads fine, so making a reduced testcase is going to be awkward.

Comment 3

[Frank Wein [:mcsmurf]]

Regressed between 2005-04-05-06 and 2005-04-06-06 (that was the day of the
freeze :/).

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Likekly candidates from that range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-05+06%3A00%3A00&maxdate=2005-04-06+06%3A00%3A00&cvsroot=%2Fcvsroot

Bug 286000 Implement BindToTree
Bug 283897 vBulletin 3.0.1 WYSIWYG Post Reply Function is Broken

CCing Boris and Johnny since they were involved with both patches.

Comment 5

[Frank Wein [:mcsmurf]]

Complete Stacktrace (the talkback one only shows one frame):
nsHTMLDocument::MatchLinks(nsIContent * 0x0443f820, int 0x00000000, nsIAtom *
0x00000000, const nsAString & {...}) line 1689 + 14 bytes
nsContentList::Match(nsIContent * 0x0443f820) line 699 + 36 bytes
nsContentList::MatchSelf(nsIContent * 0x0443f820) line 741 + 12 bytes
nsContentList::ContentAppended(nsIDocument * 0x03b5f648, nsIContent *
0x04415c68, int 0x00000001) line 612 + 27 bytes
nsDocument::ContentAppended(nsIContent * 0x04415c68, int 0x00000001) line 2134
nsHTMLDocument::ContentAppended(nsIContent * 0x04415c68, int 0x00000001) line 1081
HTMLContentSink::NotifyAppend(nsIContent * 0x04415c68, unsigned int 0x00000001)
line 3944
SinkContext::CloseContainer(nsHTMLTag eHTMLTag_strong) line 1360
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x043213a0, nsHTMLTag
eHTMLTag_strong) line 2978 + 18 bytes
CNavDTD::CloseContainer(nsHTMLTag eHTMLTag_strong, nsHTMLTag eHTMLTag_div, int
0x00000000) line 3405 + 34 bytes
CNavDTD::CloseContainersTo(int 0x0000000d, nsHTMLTag eHTMLTag_div, int
0x00000000) line 3437 + 20 bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_div, int 0x00000000) line 3595 +
20 bytes
CNavDTD::HandleEndToken(CToken * 0x043dacd8) line 1978 + 14 bytes
CNavDTD::HandleToken(CNavDTD * const 0x04338d38, CToken * 0x043dacd8, nsIParser
* 0x043211d8) line 957 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x04338d38, nsIParser * 0x043211d8,
nsITokenizer * 0x04339078, nsITokenObserver * 0x00000000, nsIContentSink *
0x043213a0) line 461 + 20 bytes
nsParser::BuildModel(nsParser * const 0x043211d8) line 2075 + 34 bytes
nsParser::ResumeParse(int 0x00000001, int 0x00000001, int 0x00000001) line 1942
+ 12 bytes
nsParser::ContinueInterruptedParsing(nsParser * const 0x043211d8) line 1451 + 19
bytes
nsContentSink::ScriptEvaluated(nsContentSink * const 0x04321354, unsigned int
0x00000000, nsIScriptElement * 0x03624dc4, int 0x00000000, int 0x00000001) line 279
nsScriptLoaderObserverProxy::ScriptEvaluated(nsScriptLoaderObserverProxy * const
0x043214b8, unsigned int 0x00000000, nsIScriptElement * 0x03624dc4, int
0x00000000, int 0x00000001) line 134 + 39 bytes
nsScriptLoader::FireScriptEvaluated(unsigned int 0x00000000, nsScriptLoadRequest
* 0x03410070) line 667
nsScriptLoader::ProcessRequest(nsScriptLoadRequest * 0x03410070) line 632
nsScriptLoader::OnStreamComplete(nsScriptLoader * const 0x0432154c,
nsIStreamLoader * 0x036cf618, nsISupports * 0x03410070, unsigned int 0x00000000,
unsigned int 0xffffffff, const unsigned char * 0x03b40685) line 973
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x036cf61c, nsIRequest *
0x0353c790, nsISupports * 0x03410070, unsigned int 0x00000000) line 137
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x04358818,
nsIRequest * 0x0353c790, nsISupports * 0x03410070, unsigned int 0x00000000) line 66
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x0353c798, nsIRequest *
0x036d6e18, nsISupports * 0x00000000, unsigned int 0x00000000) line 3811
nsInputStreamPump::OnStateStop() line 507

Assertions before crash:
###!!! ASSERTION: We should not get in here if aContainer is in some _other_ docum
ent!: 'aContainer->GetDocument() == mDocument', file d:/mozilla/tree-main/mozilla/
content/base/src/nsContentList.cpp, line 897
###!!! ASSERTION: This method should never be called on content nodes that are not
 in a document!: 'aContent->IsInDoc()', file d:/mozilla/tree-main/mozilla/content/
html/document/src/nsHTMLDocument.cpp, line 1678
###!!! ASSERTION: Huh, how did this happen? This should only be used with HTML doc
uments!: 'htmldoc', file d:/mozilla/tree-main/mozilla/content/html/document/src/ns
HTMLDocument.cpp, line 1685

Comment 6

[Boris Zbarsky [:bzbarsky]]

Can someone possibly create a minimal testcase?  It looks like what's going on
is that the sink is sending ContentAppended notifications on nodes that are no
longer in the document, but I don't quite see how that can happen...

Comment 7

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050514
Firefox/1.0+ ID:2005051410
Some more talkbackIDs. For some reason the function that crashes for me has changed:
TB5852706E [@ nsHTMLDocument::SetBody]
TB5852772H [@ nsHTMLDocument::SetBody]
TB5852787E [@ nsHTMLDocument::SetBody]
TB5852799Q [@ nsHTMLDocument::SetBody]

Comment 8

[Andrew Schultz]

Attachment: testcase

this crashes linux trunk 2005051403

Comment 9

[Andrew Schultz]

> When I save the webpage to HD using FF1.04 and then load it into FF-trunk the
> page loads fine, so making a reduced testcase is going to be awkward.

I'm guessing you used "save as web page complete" or didn't add a BASE tag. 
Never do that when attempting to create a testcase -- it mangles a lot of
things.  Save as html, and then add a BASE tag to the document (in HEAD is
generally fine):
<base href="http://www.powweb.com/">

Comment 10

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050514
Firefox/1.0+ ID:2005051410

Testcase crashes me. TBID TB5853644H [@ nsHTMLDocument::SetBody]
Thanks for the tip, andrew.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Not a patch for this bug

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Er... the real patch

Comment 13

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050515
Firefox/1.0+

With the patch applied neither the testcase nor nor the index site crash.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 183655 [details] [diff] [review]
Er... the real patch

requesting 1.8b2 approval.  This is a pretty straightforward crash fix...

Comment 15

[Asa Dotzler [:asa]]

Comment on attachment 183655 [details] [diff] [review]
Er... the real patch

a=asa

Comment 16

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 17

[timeless]

*** Bug 307060 has been marked as a duplicate of this bug. ***

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 307060 has been marked as a duplicate of this bug. ***

Comment 19

[Bob Clary [:bc] (inactive)]

content/html/document/crashtests/294235-1.html
http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3