82042 - infinite recursion whin document.writing the result of an eval

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

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

Comment 1

[anthonyd]

we have the offending line, just need to qqhip a quick testcase for this.
also, not a table specific bug, reassigning to core owner.

Comment 2

[Kevin McCluskey (gone)]

Stack looks like its stuck in parser land. Reassigning to Harish.

Comment 3

[harishd]

Mitch: I don't see the problem anymore. Do you?

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Yes, I still see the problem in recent debug builds on Windows and Linux.

Comment 5

[Christopher Hoess (gone)]

->parser

Comment 6

[harishd]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase (HANGS)

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.... :(

Comment 9

[Nicholas Allen]

Absolutely no callbacks are being made, this will never terminate.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hmm... I guess we never actually finish a single function call here, right?

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Boris Zbarsky [:bzbarsky]]

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).

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

This is WFM. I get "too much recursion", though that is sometimes a bit late, 
for some reason. But anyway, no crash, no hang.