11016 - [BLOCKER] Opening a document in xul causes a crash

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Stephen P. Morse]

Bring up the following xul file in the browser. It will give the crash shown
below.

This is a blocking bug because it prevents me from rewriting the four wallet
viewers from html to xul.

XUL file:
<?xml version="1.0"?>
<!DOCTYPE window>
<xul:window xmlns="http://www.w3.org/TR/REC-html40"
      xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
      onload = "dump('hello once more');">
  <script>
    function loadFrames(){
      dump("about the crash\n"); // This prints out
      top.frames[1].document.open();
      dump("after the crash\n"); // This does not print
      top.frames[1].document.close();
    }
  </script>
<frameset rows = "50,25"
         border="10"
         onload="loadFrames();">
  <frame src="about:blank"/>
  <frame src="about:blank"/>
</frameset>
</xul:window>

Stack Trace at time of crash:

00000000()
nsIOService::NewChannelFromURI(nsIOService * const 0x00ac61e0, const char *
0x0188f9c4, nsIURI * 0x0012e884, nsIEventSinkGetter * 0x00000000, nsIChannel * *
0x0012e800) line 219 + 37 bytes
NS_OpenURI(nsIChannel * * 0x0012e860, nsIURI * 0x0012e884) line 62 + 27 bytes
nsHTMLDocument::OpenCommon(nsIURI * 0x0012e884) line 1434 + 33 bytes
nsHTMLDocument::Open(nsHTMLDocument * const 0x0a740118, JSContext * 0x0a17c370,
long * 0x00cf0718, unsigned int 0) line 1526 + 18 bytes
NSHTMLDocumentOpen(JSContext * 0x0a17c370, JSObject * 0x00d189a8, unsigned int
0, long * 0x00cf0718, long * 0x0012e960) line 1088 + 24 bytes
js_Invoke(JSContext * 0x0a17c370, unsigned int 0, unsigned int 0) line 654 + 26
bytes
js_Interpret(JSContext * 0x0a17c370, long * 0x0012f18c) line 2228 + 15 bytes
js_Invoke(JSContext * 0x0a17c370, unsigned int 0, unsigned int 0) line 670 + 13
bytes
js_Interpret(JSContext * 0x0a17c370, long * 0x0012f974) line 2228 + 15 bytes
js_Invoke(JSContext * 0x0a17c370, unsigned int 1, unsigned int 2) line 670 + 13
bytes
js_InternalCall(JSContext * 0x0a17c370, JSObject * 0x00d03a70, long 13648456,
unsigned int 1, long * 0x0012fab4, long * 0x0012fabc) line 747 + 15 bytes
JS_CallFunctionValue(JSContext * 0x0a17c370, JSObject * 0x00d03a70, long
13648456, unsigned int 1, long * 0x0012fab4, long * 0x0012fabc) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0a780fa0) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012fc88, nsIDOMEvent * * 0x0012fbf0, unsigned int 3, nsEventStatus &
nsEventStatus_eIgnore) line 958 + 21 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0a17c534,
nsIPresContext & {...}, nsEvent * 0x0012fc88, nsIDOMEvent * * 0x0012fbf0,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2761
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x0a17aa14, nsIDocumentLoader *
0x0a2c6200, nsIChannel * 0x0a187f30, int 0, nsIDocumentLoaderObserver *
0x0a17aa14) line 2981 + 34 bytes
nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x0a2c6200, int 0)
line 1122
nsDocLoaderImpl::ChildDocLoaderFiredEndDocumentLoad(nsDocLoaderImpl *
0x0a2c6200, nsIDocumentLoader * 0x0a2c6200, int 0) line 1145
nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x0a2c6200, int 0)
line 1130
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x0a2c6204, nsIChannel *
0x0a2d6ee0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 1029
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0a747380) line
274
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0a747384) line 149 + 12 bytes
PL_HandleEvent(PLEvent * 0x0a747384) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ad4f40) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x01b801ec, unsigned int 49387, unsigned int 0,
long 11358016) line 932 + 9 bytes
USER32! 77e71268()
00ad4f4

Comment 1

[Paul MacQuiddy]

this does not crash in the final non-necko builds of 7/26 at
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-07-26-16-M9/
You see a blank page with a top and bottom frame when this page is loaded.

Comment 2

[Stephen P. Morse]

And that's exactly what you are supposed to see.  So this is a necko problem, so
I'm reassigning it to gagan and changing the component from XUL to NECO.

This may be related to 10456 and may even be a duplicate of that bug, although
I'm not prepared to make that statement at this time.  I'll leave that up to the
necko team to determine.

Comment 3

[Suresh Duddi (gone)]

I see general problems with necko and frames. I think warren was working on it.

Comment 4

[Warren Harris]

I'll take a look at this.

Comment 5

[leger]

Setting to blocker.  Need fixed for QA to test please.

Comment 6

[Warren Harris]

I opened a xul file with these contents without crashing. I'm not sure what
it's supposed to do though. Please verify if this is still a bug.

Comment 7

[Stephen P. Morse]

Sorry, still doesn't work for me.  Although now the stack trace at the time of
crash is different (see below).  And this time neither of the "dump" messages
print out (previously I was receiving the first message bug not the second.

I'm running a tree that I pulled on Wednesday morning.  Reopening.

NTDLL! 77f76274()
nsExpatTokenizer::GetLine(const char * 0x09eb7028, unsigned int 1300, unsigned
int 0, nsString & {...}) line 199 + 43 bytes
nsExpatTokenizer::PushXMLErrorToken(const char * 0x09eb7028, unsigned int 1300,
int 0) line 271
nsExpatTokenizer::ParseXMLBuffer(const char * 0x09eb7028, unsigned int 1300, int
0) line 289
nsExpatTokenizer::ConsumeToken(nsScanner & {...}) line 330 + 18 bytes
nsParser::Tokenize(int 0) line 1264 + 21 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 885 + 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x0a3454b4, nsIChannel * 0x0a3465e0,
nsISupports * 0x00000000, nsIInputStream * 0x0a3462e0, unsigned int 0, unsigned
int 650) line 1168 + 19 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x0a346820,
nsIChannel * 0x0a3465e0, nsISupports * 0x00000000, nsIInputStream * 0x0a3462e0,
unsigned int 0, unsigned int 650) line 2057 + 32 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0a346280)
line 350
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0a346284) line 149 + 12 bytes
PL_HandleEvent(PLEvent * 0x0a346284) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00afaf50) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00e20530, unsigned int 49350, unsigned int 0,
long 11513680) line 932 + 9 bytes
USER32! 77e71268()
00afaf50()

Comment 8

[Stephen P. Morse]

Just to rule out a stale tree as the reason it still crashes for me, I just
pulled and build a completely fresh tree.  Still crashes with the new stack
trace shown above.

Comment 9

[Warren Harris]

Well, this stack trace is clearly not a necko problem. Looks like a problem in
expat.

Comment 10

[Chris Waterson]

Fixed. nsHTMLDocument::GetSourceDocumentURL() was sloppy wrt. ensuring that the
result parameter was zeroed.

Comment 11

[Stephen P. Morse]

Nope, still not fixed.  I just pulled a fresh tree this and tried the test case
in this bug report and got the same crash reported previously.  Reproducing here
below because the line numbers are slightly different this time (to be expected
if the code has been modified).

Reopening again.

NTDLL! 77f76274()
nsExpatTokenizer::GetLine(const char * 0x00d7f6f8, unsigned int 1296, unsigned
int 0, nsString & {...}) line 199 + 43 bytes
nsExpatTokenizer::PushXMLErrorToken(const char * 0x00d7f6f8, unsigned int 1296,
int 0) line 271
nsExpatTokenizer::ParseXMLBuffer(const char * 0x00d7f6f8, unsigned int 1296, int
0) line 289
nsExpatTokenizer::ConsumeToken(nsScanner & {...}) line 330 + 18 bytes
nsParser::Tokenize(int 0) line 1264 + 21 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 885 + 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x02c18b94, nsIChannel * 0x02c1ff80,
nsISupports * 0x00000000, nsIInputStream * 0x02c1c150, unsigned int 0, unsigned
int 648) line 1168 + 19 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x02c1c640,
nsIChannel * 0x02c1ff80, nsISupports * 0x00000000, nsIInputStream * 0x02c1c150,
unsigned int 0, unsigned int 648) line 2057 + 32 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x02c1c9b0)
line 350
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02c1c9b4) line 149 + 12 bytes
PL_HandleEvent(PLEvent * 0x02c1c9b4) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00afb8c0) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00f102d4, unsigned int 49407, unsigned int 0,
long 11516096) line 932 + 9 bytes
USER32! 77e71268()
00afb8c

Comment 12

[Chris Waterson]

Hey Steve, I just re-tested this file and it WORKSFORME. Are you sure that you
picked up the changes to nsHTMLDocument.cpp?

Some ideas:

1. Might there be some whitespace (or other) difference between the file that I
have and your version? (I cut-and-pasted from the bug report into a local
file.)

2. Might you be using a file extension other than ".xul"? (I saved the file as
"11016.xul", but have also tried this as ".html" and ".xml" and it still
works.)

3. Do you have any local mods in your tree? (I doubt you'd be monkeying around
with expat, but...)

FWIW, I was seeing the _original_ crash that you reported (that's what I
"fixed"). Could this be an uninitialized memory problem? (Which would explain
why it seems to work for me and not you...)

Comment 13

[Stephen P. Morse]

1. I did a stat on that file.  I have version 3.141 and that is the latest
version in the repository.

2. My file extension is definitely .xul.  I also tried it as .html (by accident)
and it didn't crash -- all it gave me was a screen saying "XUL file:"

3. I tried this before making any local mods what-so-ever.

Comment 14

[leger]

What is status for M9 branch check in?

Comment 15

[Stephen P. Morse]

I'm not the one who set it to M9 so I can't say.  But I don't think this is an
M9 showstopper.  Rather it is a blocker for development work.

Comment 16

[leger]

Sound good...moving to M10...we have plenty of M9 blockers to keep us busy :-)
Thanks!

Comment 17

[Stephen P. Morse]

Just an update -- this bug still fails for me.  I have finally been able to get
a working tree and it is fresh as of today.  I thought for a while that the
problem might have been that I was being symlinked to some old builds but now I
have blown away all the old builds and have only the current tree.  And it
fails.

Waterson, paulmac, and harishd have tried this and it works for all of them.  So
I have no idea why this is failing but it definitely is failing.

Comment 18

[Stephen P. Morse]

OK, I figured it out.  My error.  When I copied and pasted the sample xul file
presented here, I also copied the lead line that says "XUL file:".  With that
line, the crash occured and without it there was no crash.  So Chris' change
indeed fixed this bug and I'll close out this report as fixed.  But I've also
opened up a report about a file containing a "XUL file:" line.  See bug 12259.

Comment 19

[ckritzer (gone)]

Verified fixed on:
1999082412 WinNT

Also tested on:
1999082409 MacOS86 - appears to work
1999082408 Linux6 - appears to work

Comment 20

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.