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)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: security-bugs, Assigned: jst)

Details

(Keywords: hang)

Attachments

(1 file)

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]
Stack looks like its stuck in parser land. Reassigning to Harish.
Assignee: attinasi → harishd
Mitch: I don't see the problem anymore. Do you?
Yes, I still see the problem in recent debug builds on Windows and Linux.
->parser
Component: Layout → Parser
QA Contact: petersen → moied
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
Component: Parser → DOM Core
Attached file Testcase (HANGS) (deleted) —
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
Absolutely no callbacks are being made, this will never terminate.
Whiteboard: [NEED TESTCASE]
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.
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
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
Component: DOM: Core → DOM: Core & HTML
QA Contact: moied → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: