Crash loading xul file

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
18 years ago
11 years ago

People

(Reporter: bugzilla, Assigned: hyatt)

Tracking

({crash, helpwanted})

Trunk
Future
x86
Windows ME
crash, helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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...
(Reporter)

Comment 1

18 years ago
Created attachment 21120 [details]
file that crashes
(Reporter)

Comment 2

18 years ago
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()
Keywords: crash

Comment 3

18 years ago
Thanks Blake!
->hyatt, cc waterson
Assignee: trudelle → hyatt

Comment 4

18 years ago
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).
(Reporter)

Comment 5

18 years ago
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...

Comment 6

18 years ago
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
Keywords: helpwanted
Target Milestone: --- → Future

Comment 7

18 years ago
This might be related to bug 86665 or vice versa?!

Comment 8

17 years ago
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

Updated

11 years ago
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.