Reported via Talkback System User Comments : Loading XML document. Stack Trace :- nsXMLDocument::EndLoad [d:\builds\seamonkey\mozilla\layout\xml\document\src\nsXMLDocument.cpp, line 579] nsXMLContentSink::StartLayoutProcess [d:\builds\seamonkey\mozilla\layout\xml\document\src\nsXMLContentSink.cpp, line 327] nsXMLContentSink::DidBuildModel [d:\builds\seamonkey\mozilla\layout\xml\document\src\nsXMLContentSink.cpp, line 313] CWellFormedDTD::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 312] nsParser::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 991] nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1466] nsParser::EnableParser [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1089] CSSLoaderImpl::Cleanup [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 748] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 818] CSSLoaderImpl::Cleanup [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 729] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 818] CSSLoaderImpl::Cleanup [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 729] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 818] CSSLoaderImpl::Cleanup [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 729] CSSLoaderImpl::SheetComplete [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 818] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 853] CSSLoaderImpl::DidLoadStyle [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 889] SheetLoadData::OnStreamComplete [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 686] nsStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp, line 122] nsResChannel::EndRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\res\src\nsResChannel.cpp, line 767] nsResChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\res\src\nsResChannel.cpp, line 752] nsFileChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line 627] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 307] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 576] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 539] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1032] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00688bd2 Code Around the crash : - NS_IMETHODIMP 575 nsXMLDocument::EndLoad() 576 { 577 nisheeth 1.64 nsAutoString cmd; 578 jst 1.68 if (mParser) mParser->GetCommand(cmd); 579 vidur 1.1 NS_IF_RELEASE(mParser); 580 nisheeth 1.64 if (cmd.EqualsWithConversion(kLoadAsData)) { 581 // Generate a document load event for the case when an XML document was loaded 582 // as pure data without any presentation attached to it. 583 nsCOMPtr<nsIScriptGlobalObject> scriptGlobal; 584 nsEventStatus status = nsEventStatus_eIgnore; 585 nsMouseEvent event; 586 event.eventStructType = NS_EVENT; 587 event.message = NS_PAGE_LOAD; 588 HandleDOMEvent(nsnull, &event, nsnull, NS_EVENT_FLAG_INIT, &status); 589 } 590 return nsDocument::EndLoad(); 591 vidur 1.1 }

Adding keywords crash and topcrash.

Marking nsbeta2. Setting target milestone to M17...

Putting on [nsbeta2+][w/b minus on 6/15] radar.

PDT: please leave nsbeta2+ because XML documents are crashing after being loaded. Nisheeth has Target Milestone set to M17.

On closer examination, this crash only happens when the new XML document load from script functionality is exercised. This bug probably happens when the new functionlity is used incorrectly. I can't fix this bug until I know more about what the user was doing on his end to cause this crash. I don't think this needs to be a beta2 blocker because this does not crash on the regular XML document load code path. Please let this fall off the beta 2 radar after today.

Putting onto nsbeta3 radar...

Setting milestone to M18...

Marking nsbeta2-, now that the 6/15 date has passed.

nsbeta3+

Marking this beta3-. Will educate developers to use this functionality in the right way. There is also a more robust alternative for out of band XML loading in the XML Extras component. This bug has been marked nsbeta3- because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration, but do not clear the nsbeta3- nomination.

IMO, this should be fixed before release. While you can educate developers about the right way, there's nothing to prevent malicious web pages (or even email?) from crashing the user's browser. Is there some hack you can use to prevent a crash and just fail instead? Clearing nsbeta3- for reconsideration.

[This is ekrock.] Yes, you're exactly right that there's nothing to prevent malicious web pages from crashing the user's browser, and malicious web pages are not our concern at this point in the project. Shipping a stable, performant browser for regular web pages is the priority. [nsbeta3-].

Can we get a testcase for this? If I understand the description correctly, it would be possible to use this bug to crash the browser remotely using mail or the instant messenger client. Is this correct?

How to reproduce this ? There are no reproduce step in this bug....

In light of no new information, marking this rtm- again. If any more information on reproducing this is found, please re-nominate. Thanks.

Since no new information to reproduce this bug has been added, further progress on this particular bug cannot be made. Removing topcrash keyword to keep this bug from appearing on the Key Bug Metrics published by chofmann.

And futuring this bug. If you can provide steps on reproducing this bug, please set the target milestone to "---" to bring this bug back onto my radar. Thanks.

jpatel, can you rerun the analysis on the N6 rtm to see where this stack signature falls out. If its no longer visable then we can keep the top crash keyword off this bug. If folks are still seeing it then lets add some more comments, urls, and possible test cases.

From the collected RTM data, I don't see this particular crash in the topcrash lists anywhere. I think it might have been an easily reproducible crash for Shiva, but other users did not seem to run into this problem enough for it to show up as a topcrasher. Shiva (namachi@netscape.com) might be able to provide a test case for this crash.

I am experiencing what I believe is the problem described in this bug, and have attached three files that reproduce it for me. There is one XUL file whose only purpose is to load the JavaScript and call my XMLHttpRequest wrapper with a URL as an argument. There is one JavaScript file which calls XMLHttpRequest in a very simple (and I believe) valid manner. Finally, I have attached an XML file that reproduces the problem. I am currently reproducing this problem on .8.1 on Win2K, and am not able to with .8. The only distinguishing factor that seems to affect whether or not the XML file loads or not is size (not line length, or node count, but byte- length). I have seen the size of the file necessary to trigger the problem vary from run to run, so I can't pinpoint it exactly. If this file doesn't trigger the problem for you, try doubling the number of child nodes. If this file does trigger the problem, halving them should make it go away. I'm happy to provide more info/test cases if needed. For me this is an urgent problem since I can't use anything past .8 until it is fixed.

The problem tupshin is describing belongs into another bug, see bug 73958.

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

I don't think I have ever seen this crash, and the XML parsing code has changed a lot since this bug was opened. Marking worksforme. If you can still reproduce this, please reopen.