[BLOCKER] Opening a document in xul causes a crash

VERIFIED FIXED in M10

Status

()

defect
P3
blocker
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: morse, Assigned: rickg)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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
Blocks: 10240
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.
Assignee: trudelle → gagan
Component: XUL → Necko
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.
I see general problems with necko and frames. I think warren was working on it.
Assignee: gagan → warren
I'll take a look at this.
Status: NEW → ASSIGNED
Target Milestone: M9
Severity: normal → blocker
Summary: [BLOC] Opening a document in xul causes a crash → [BLOCKER] Opening a document in xul causes a crash
Setting to blocker.  Need fixed for QA to test please.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
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()
Resolution: WORKSFORME → ---
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.
Blocks: 10406
Assignee: warren → rickg
Status: REOPENED → NEW
Well, this stack trace is clearly not a necko problem. Looks like a problem in
expat.
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Fixed. nsHTMLDocument::GetSourceDocumentURL() was sloppy wrt. ensuring that the
result parameter was zeroed.
Status: RESOLVED → REOPENED
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
Resolution: FIXED → ---
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...)
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.
Blocks: 7530
What is status for M9 branch check in?
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.
Target Milestone: M9 → M10
Sound good...moving to M10...we have plenty of M9 blockers to keep us busy :-)
Thanks!
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Verified fixed on:
1999082412 WinNT

Also tested on:
1999082409 MacOS86 - appears to work
1999082408 Linux6 - appears to work
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
You need to log in before you can comment on or make changes to this bug.