While making a testcase for another bug, I came across a crash...this file is probably invalid in some regard, since I was in the process of making the testcase, but we still shouldn't crash. Attaching the complete file, then I'll start minimizing it...
Stack: 5059fb7b() XULContentSinkImpl::~XULContentSinkImpl() line 469 + 51 bytes XULContentSinkImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes XULContentSinkImpl::Release(XULContentSinkImpl * const 0x02aff400) line 510 + 154 bytes nsParser::~nsParser() line 273 + 27 bytes nsParser::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsParser::Release(nsParser * const 0x03400590) line 284 + 154 bytes nsCOMPtr<nsIStreamListener>::assign_assuming_AddRef(nsIStreamListener * 0x00000000) line 471 nsCOMPtr<nsIStreamListener>::assign_with_AddRef(nsISupports * 0x00000000) line 951 nsCOMPtr<nsIStreamListener>::operator=(nsIStreamListener * 0x00000000) line 583 nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x033ffa20, nsIChannel * 0x033ff8a0, nsISupports * 0x00000000, unsigned int 2152596471, const unsigned short * 0x100acc48 gCommonEmptyBuffer) line 279 nsFileChannel::OnStopRequest(nsFileChannel * const 0x033ff8a8, nsIChannel * 0x03404270, nsISupports * 0x00000000, unsigned int 2152596471, const unsigned short * 0x100acc48 gCommonEmptyBuffer) line 652 + 45 bytes nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x033e1e40) line 300 + 46 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x033e1e50) line 92 + 12 bytes PL_HandleEvent(PLEvent * 0x033e1e50) line 576 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00fd7ec0) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00000bc4, unsigned int 57386, unsigned int 0, long 16613056) line 1054 + 9 bytes KERNEL32! bff63613() KERNEL32! bff848f7() 007b8a22()
Thanks Blake! ->hyatt, cc waterson
Assignee: trudelle → hyatt
Well, trudelle's last CC: didn't take, so adding it now. At any rate, the file that crashes is not well-formed: it fails to close a </treecell>, a </treerow>, a </treehead> and the </tree>. (Just add those four closing tags above </window>, and the crash is gone). (Not sure about how XUL and RDF get notifications from the XML parser, but I suppose there could be some for an ill-formed document to trigger an abort of building the content).
Yup. The weird thing is that the testcase needs to be pretty complex to crash. I tried taking out whole chunks of stuff, like the <treecolgroup/> and the <script/>, and in each case it then failed to crash, and instead complained about the malformed document. Even removing one in a series of <treecell/>'s prevented the crash...
More error checking would be good, but unfortunately it doesn't look like hyatt will have time for this in the next (short) release cycle. ->future/helpwanted
Target Milestone: --- → Future
This might be related to bug 86665 or vice versa?!
WORKSFORME in 0.9.4 - the bad XML is diagnosed. Fixing the closing tags for tree lets it render even.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.