Stephen P. Morse Reporter
	Description • 25 years ago

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

	Paul MacQuiddy
	Comment 1 • 25 years ago

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.

	Stephen P. Morse Reporter
	Comment 2 • 25 years ago

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.

	Suresh Duddi (gone)
	Comment 3 • 25 years ago

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

	Warren Harris
	Comment 4 • 25 years ago

I'll take a look at this.

	leger
	Comment 5 • 25 years ago

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

	Warren Harris
	Comment 6 • 25 years ago

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.

	Stephen P. Morse Reporter
	Comment 7 • 25 years ago

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()

	Stephen P. Morse Reporter
	Comment 8 • 25 years ago

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.

	Warren Harris
	Comment 9 • 25 years ago

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

	Chris Waterson
	Comment 10 • 25 years ago

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

	Stephen P. Morse Reporter
	Comment 11 • 25 years ago

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

	Chris Waterson
	Comment 12 • 25 years ago

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...)

	Stephen P. Morse Reporter
	Comment 13 • 25 years ago

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.

	leger
	Comment 14 • 25 years ago

What is status for M9 branch check in?

	Stephen P. Morse Reporter
	Comment 15 • 25 years ago

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.

	leger
	Comment 16 • 25 years ago

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

	Stephen P. Morse Reporter
	Comment 17 • 25 years ago

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.

	Stephen P. Morse Reporter
	Comment 18 • 25 years ago

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.

	ckritzer (gone)
	Comment 19 • 25 years ago

Verified fixed on:
1999082412 WinNT

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

	leger
	Comment 20 • 25 years ago

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

component.