Closed
Bug 27235
Opened 25 years ago
Closed 25 years ago
Browser crashes when JavaScript writes a <SCRIPT SRC=""> tag
Categories
(Core :: DOM: HTML Parser, defect, P3)
Core
DOM: HTML Parser
Tracking
()
People
(Reporter: anubis, Assigned: rickg)
References
()
Details
(Keywords: crash)
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
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•25 years ago
|
||
|
|
||
Comment 2•25 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•25 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•25 years ago
|
Component: Layout → Parser
|
|
||
Comment 4•25 years ago
|
||
ah, okay, thanks. i'll get a stack trace for this when i'm at my machine
tomorrow.
Updating QA Contact. there is a Win2000 machine in the Browser lab.
Assignee: leger → rickg
QA Contact: cbegle → janc
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
|
||
Comment 7•25 years ago
|
||
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
|
|
||
Comment 8•25 years ago
|
||
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.
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
Closed: 25 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•