If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Browser crashes when JavaScript writes a <SCRIPT SRC=""> tag

VERIFIED DUPLICATE of bug 30026

Status

()

Core
HTML: Parser
P3
critical
VERIFIED DUPLICATE of bug 30026
18 years ago
17 years ago

People

(Reporter: Will Munslow, Assigned: rickg)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Here is a test page (17 lines long):

<html><head>
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
<!--
function showimage(name) {
	document.open();
	document.write ("<html><head>");
	document.write ("<SCRIPT SRC=\"checkframe.js\"><\/SCRIPT>\n");
	document.write ("</head><body>");
	document.write ("<img src='" + name + "'>\n");
	document.write ("</body></html>\n");
	document.close();
}
//-->
</SCRIPT>
</head><body>
<a href="javascript:showimage('test.jpg')">test</a>
</body></html>

When the link (test) is clicked, the JavaScript creates a new document and 
burps out the page source. The Browser crashes on the <SCRIPT 
SRC="checkframe.js"></SCRIPT> line for some unknown reason. Removing this line 
or changing it so it does not contain a SRC attribute seems to work fine.

It doesn't seem to be a JavaScript problem. If you change the line:
document.write ("<SCRIPT SRC=\"checkframe.js\"><\/SCRIPT>\n");

to
document.write ("<!-- <SCRIPT SRC=\"checkframe.js\"><\/SCRIPT> -->\n");

it works like a champ. The JavaScript has no problem writing it, it just seems 
that the browser has a problem displaying it.

Comment 1

18 years ago
Created attachment 5132 [details]
the script in the body of the bug report

Comment 2

18 years ago
        GKHTML.DLL attempted to use a null data pointer variable.
        Module Name: GKHTML.DLL
        Application Name: Mozilla.exe
  
this is reproducible.  anubis@suberrane.com, can you provide a stack trace or 
Dr. Watson log?  
Component: Browser-General → Layout
(Reporter)

Comment 3

18 years ago
I'm not sure how useful I'll be. This isn't captured by Dr. Watson because I 
have MSDev installed. I get "Unhandled exception in mozilla.exe
(GKPARSER.DLL):0xC0000005 Access Violation" when I debug.

The call stack looks like this:
GKPARSER! 602bd346()
NECKO! 60542877()
NKCACHE! 60574851()
NKCACHE! 60577afb()

The feedback Agent says that the stack trace looks like this:
[   0] 46 D3 2B 60 E4 FC 12 00 FD 8A 99 01 EC FC 12 00 [F.+`............]
[  10] 9D 8C 99 01 18 FD 12 00 77 28 54 60 40 FD 12 00 [........w(T`@...]
[  20] 51 48 57 60 64 FD 12 00 FB 7A 57 60 88 FD 12 00 [QHW`d....zW`....]
[  30] 2F 22 54 60 A0 FD 12 00 7F 1E 54 60 AC FD 12 00 [/"T`......T`....]
[  40] 2E 19 BF 60 D4 FD 12 00 C0 1B BF 60 E0 FD 12 00 [...`.......`....]
[  50] F8 35 E1 77 00 FE 12 00 69 37 E1 77 8C FE 12 00 [.5.w....i7.w....]
[  60] 9A 7B E1 77 CC FE 12 00 82 1E 01 60 D4 FE 12 00 [.{.w.......`....]
[  70] A3 18 40 00 18 FF 12 00 50 15 40 00 4C FF 12 00 [..@.....P.@.L...]
[  80] 83 26 40 00 C0 FF 12 00 52 BC E9 77 F0 FF 12 00 [.&@.....R..w....]

Does this help?

Updated

18 years ago
Component: Layout → Parser

Comment 4

18 years ago
ah, okay, thanks.  i'll get a stack trace for this when i'm at my machine 
tomorrow.

Comment 5

18 years ago
Updating QA Contact.  there is a Win2000 machine in the Browser lab.
Assignee: leger → rickg
QA Contact: cbegle → janc
(Assignee)

Comment 6

18 years ago
Here's the stack trace on NT. The culprit appears to be in the DOM accessor 
methods. Forwarding the bug to Vidur for further examination.

nsDebug::Assertion(const char * 0x017d8cf4, const char * 0x017d8cbc, const char 
* 0x017d8c94, int 764) line 189 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x017d8cf4, const char * 0x017d8cbc, const 
char * 0x017d8c94, int 764) line 247 + 21 bytes
nsDocShell::GetChildAt(nsDocShell * const 0x015983a8, int 0, nsIDocShellTreeItem 
* * 0x0012f1c4) line 764 + 61 bytes
nsDOMWindowList::Item(nsDOMWindowList * const 0x0244b260, unsigned int 0, 
nsIDOMWindow * * 0x0012f2b0) line 118 + 46 bytes
GetWindowCollectionProperty(JSContext * 0x023ea890, JSObject * 0x01149910, long 
1, long * 0x0012fa70) line 99 + 22 bytes
js_GetProperty(JSContext * 0x023ea890, JSObject * 0x01149910, long 1, long * 
0x0012fa70) line 1910 + 131 bytes
js_Interpret(JSContext * 0x023ea890, long * 0x0012fc70) line 2264 + 1564 bytes
js_Execute(JSContext * 0x023ea890, JSObject * 0x01131d48, JSScript * 0x0244b350, 
JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0, long * 
0x0012fc70) line 836 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x023ea890, JSObject * 0x01131d48, 
JSPrincipals * 0x0244d8f4, const unsigned short * 0x0244d130, unsigned int 107, 
const char * 0x0244d520, unsigned int 0, long * 0x0012fc70) line 2743 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x023ebfc0, const nsString & 
{???}, void * 0x01131d48, nsIPrincipal * 0x0244d8f0, const char * 0x0244d520, 
unsigned int 0, const char * 0x004ea468, nsString & {???}, int * 0x0012fcd0) 
line 292 + 53 bytes
HTMLContentSink::EvaluateScript(nsString & {???}, int 0, const char * 
0x004ea468) line 4149
HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x028742e4, 
nsIStreamLoader * 0x0244fc60, nsISupports * 0x00000000, unsigned int 0, unsigned 
int 107, const char * 0x0244b460) line 4171 + 27 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0244fc64, nsIChannel * 
0x0244f8e0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x00000000) line 111 + 75 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 
0x0244b790, nsIChannel * 0x0244f8e0, nsISupports * 0x00000000, unsigned int 0, 
const unsigned short * 0x00000000) line 1118
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x0244b790, unsigned int 0, 
const unsigned short * 0x00000000) line 1315 + 36 bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x0244a750, 
nsIChannel * 0x0244de44, nsISupports * 0x0244f8e0, unsigned int 0, const 
unsigned short * 0x00000000) line 412
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0244d080) line 
292
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0244d030) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x0244d030) line 556 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x012a8b90) line 501 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0ac80292, unsigned int 49322, unsigned int 0, 
long 19565456) line 1011 + 9 bytes
USER32! 77e71820()
012a8b90()
Assignee: rickg → vidur
I've got this working in my tree now, and it is a parser problem. (Rickg, the
above stacktrace is not a crash, just an assetrion and AFAIK it's not related
to this, it's happening inside the script your testcase is loading) Here's what
happens when you click on the link.

The javascript is executed and starts writing the content, this causes a parser
to be created and nsParser::Parse(nsString...) is called multiple times. On
every call ResumeParse() is called and thus the content sink is notified on
every document.write(). The content sink sees the script tag, tells necko to
load the script and the parser is blocked, then the JS continues with the rest
of the document.write() calls and actually finishes before the script is fully
loaded. When document.close() is called the parser sees it as the last call to
the sequence of document.write()'s and does a PopContext() to clean up after
the parsing, now, since there's only one context mParserContext is nsnull afrer
the parser calls PopContext(). Then, some time later the JavaScript finishes
loading and tells the content sink that it's done, then the content sink tells
the parser to continue where it was blocked by calling EnableParser(). Now, in
nsParser::EnableParser() there are a few checks that assume that there's a
valid mParserContext but in this case mParserContext is nsnull! This is the
real crash in this bug (you might se other focus related crashes too while
experimenting with this, but I've got a fix for those too).

This patch fixes the crash and makes the testcase work:

Index: src/nsParser.cpp
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/nsParser.cpp,v
retrieving revision 3.176
diff -u -r3.176 nsParser.cpp
--- src/nsParser.cpp    2000/03/07 02:35:20     3.176
+++ src/nsParser.cpp    2000/03/09 02:21:54
@@ -980,7 +980,7 @@
       pc->mMultipart=!aLastCall;
     }
     result=ResumeParse();
-    if(aLastCall) {
+    if(aLastCall && mParserContext->mPrevContext) {
       pc->mScanner->CopyUnusedData(mUnusedInput);
       pc=PopContext();
       delete pc;

I don't know if this is the correct fix for the above scenario tho, reassigning 
back to rickg for evaluation. (also marking all/all since this is XP)
Assignee: vidur → rickg
OS: Windows 2000 → All
Hardware: PC → All
Actually, something like this might make a bit more sence here...

Index: nsParser.cpp
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/nsParser.cpp,v
retrieving revision 3.176
diff -u -r3.176 nsParser.cpp
--- nsParser.cpp        2000/03/07 02:35:20     3.176
+++ nsParser.cpp        2000/03/09 03:46:03
@@ -980,7 +980,7 @@
       pc->mMultipart=!aLastCall;
     }
     result=ResumeParse();
-    if(aLastCall) {
+    if(aLastCall && pc->mParserEnabled) {
       pc->mScanner->CopyUnusedData(mUnusedInput);
       pc=PopContext();
       delete pc;

I haven't tried to run mozilla with this version of the patch but it should
work.
(Assignee)

Comment 9

18 years ago
I've come to the same conclusion, johnny, working on bug 30026. But that's only 
part of the problem. The ResumeParser method also needs to iterate open 
ParserContexts.

*** This bug has been marked as a duplicate of 30026 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 10

17 years ago
Adding crash keyword
Keywords: crash

Comment 11

17 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.