Closed
Bug 82042
Opened 23 years ago
Closed 18 years ago
infinite recursion whin document.writing the result of an eval
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: security-bugs, Assigned: jst)
Details
(Keywords: hang)
Attachments
(1 file)
(deleted),
text/html
|
Details |
Running this script:
<SCRIPT>
document.write(eval("document.body.innerHTML"));
</SCRIPT>
causes an infinite recursion. Not sure who this should go to, trying Layout.
Here's one cycle of the stack trace:
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4657
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x04b21040, const nsIParserNode
& {...}) line 3141 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x052fea00) line 3760 + 22 bytes
CNavDTD::HandleScriptToken(const nsIParserNode * 0x052fea00) line 2237 + 12 bytes
CNavDTD::OpenContainer(const nsCParserNode * 0x052fea00, nsHTMLTag
eHTMLTag_script, int 1, nsEntryStack * 0x00000000) line 3418 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x05342310, nsHTMLTag eHTMLTag_script,
nsCParserNode * 0x052fea00) line 1314 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x05342310) line 1723 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x04b41ba0, CToken * 0x00000000, nsIParser
* 0x04b1fe50) line 887 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x04b41ba0, nsIParser * 0x04b1fe50,
nsITokenizer * 0x04dcb5b0, nsITokenObserver * 0x00000000, nsIContentSink *
0x04b21040) line 539 + 20 bytes
nsParser::BuildModel() line 1990 + 34 bytes
nsParser::ResumeParse(int 0, int 0) line 1871 + 11 bytes
nsParser::Parse(const nsAString & {...}, void * 0x0000005d, const nsString &
{...}, int 0, int 1, nsDTDMode eDTDMode_autodetect) line 1733 + 15 bytes
nsHTMLDocument::WriteCommon(const nsAString & {...}, int 0) line 2327 + 201 bytes
nsHTMLDocument::ScriptWriteCommon(int 0) line 2424 + 19 bytes
nsHTMLDocument::Write(nsHTMLDocument * const 0x04b1ea28) line 2451
XPTC_InvokeByIndex(nsISupports * 0x04b1ea28, unsigned int 19, unsigned int 0,
nsXPTCVariant * 0x000779b0) line 139
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 1835 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x03d60d80, JSObject * 0x02a8af70, unsigned int 1,
long * 0x02b87b94, long * 0x00077be4) line 1241 + 11 bytes
js_Invoke(JSContext * 0x03d60d80, unsigned int 1, unsigned int 0) line 807 + 23
bytes
js_Interpret(JSContext * 0x03d60d80, long * 0x000789fc) line 2702 + 15 bytes
js_Execute(JSContext * 0x03d60d80, JSObject * 0x02a95620, JSScript * 0x04dcba50,
JSStackFrame * 0x00000000, unsigned int 0, long * 0x000789fc) line 986 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x03d60d80, JSObject * 0x02a95620,
JSPrincipals * 0x04b6d540, const unsigned short * 0x00078b5c, unsigned int 50,
const char * 0x04dcbc10, unsigned int 377, long * 0x000789fc) line 3260 + 25 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x03d64760, const nsAString &
{...}, void * 0x02a95620, nsIPrincipal * 0x04b6d53c, const char * 0x04dcbc10,
unsigned int 377, const char * 0x00000000, nsAString & {...}, int * 0x00078a68)
line 603 + 85 bytes
nsScriptLoader::EvaluateScript(nsScriptLoadRequest * 0x04dcbcc0, const
nsAFlatString & {...}) line 569
nsScriptLoader::ProcessRequest(nsScriptLoadRequest * 0x04dcbcc0) line 481 + 22 bytes
nsScriptLoader::ProcessScriptElement(nsScriptLoader * const 0x04b23430,
nsIDOMHTMLScriptElement * 0x04dcbfd8, nsIScriptLoaderObserver * 0x04dcbfdc) line
424 + 15 bytes
nsHTMLScriptElement::SetDocument(nsHTMLScriptElement * const 0x04dcbfb0,
nsIDocument * 0x04b1e8f0, int 0, int 1) line 146
nsGenericHTMLContainerElement::AppendChildTo(nsGenericHTMLContainerElement *
const 0x04b4aa10, nsIContent * 0x04dcbfb0, int 0, int 0) line 3648
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4657
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x04b21040, const nsIParserNode
& {...}) line 3141 + 12 bytes
we have the offending line, just need to qqhip a quick testcase for this.
also, not a table specific bug, reassigning to core owner.
Assignee: karnaze → attinasi
Whiteboard: [NEED TESTCASE]
Comment 2•23 years ago
|
||
Stack looks like its stuck in parser land. Reassigning to Harish.
Assignee: attinasi → harishd
Reporter | ||
Comment 4•23 years ago
|
||
Yes, I still see the problem in recent debug builds on Windows and Linux.
May be we need some kind of a protection at the document level?
--> DOM --> jst ;)
Note: SCRIPT needs to be inside the BODY to reproduce the problem.
Assignee: harishd → jst
Updated•22 years ago
|
Component: Parser → DOM Core
Comment 7•21 years ago
|
||
Comment 8•21 years ago
|
||
So... I'm not quite sure what we should do about this. The branch callback is
not catching it either, in sane amounts of time.... :(
OS: Windows NT → All
Hardware: PC → All
Comment 9•21 years ago
|
||
Absolutely no callbacks are being made, this will never terminate.
Whiteboard: [NEED TESTCASE]
Comment 10•21 years ago
|
||
Hmm... I guess we never actually finish a single function call here, right?
Does this still crash? It really shouldn't seing that we now init the
appropriate stacksize guards which should prevent recursions to death.
Comment 12•20 years ago
|
||
I'm not seeing a crash over here.... just an infinite loop that we never break
out of (with constant memory usage too, which somewhat surprised me).
Keywords: hang
Comment 13•18 years ago
|
||
This is WFM. I get "too much recursion", though that is sometimes a bit late,
for some reason. But anyway, no crash, no hang.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•