Closed Bug 229035 Opened 22 years ago Closed 16 years ago

crash by recursive document writes of script

Categories

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

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 400792

People

(Reporter: bc, Unassigned)

Details

(Keywords: crash)

Attachments

(1 file)

Test page contains a script in the body which writes out the body of the page. The script is executed again each time it is written out, thus leading to an infinite number of writes and a crash. <html> <head> <title>crash by recursive document.writes</title> </head> <body> <p>body</p> <script type="text/javascript"> document.write(document.body.innerHTML); </script> </body> </html> Note that Opera only executes the contains script once while, IE will executes it a limited number of times (decreasing count upon refreshing page). Note that I haven't been able to get a direct crash in a debug build. The build seems to just stop, but when you close the window a crash occurs. The crash occurs pretty regularly in recent trunk and 1.4 builds but I haven't been able to get a stack for them. This is related to but not the same as bug 77271. It is more related to bug 117117. It appears other browsers set a limit on the number of times that consecutive document.writes will cause script to evaluate.
Attached file crashme
Talkback ID: TB27672913M sent to talkback.mozilla.org Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 DocWatson told me about JS3250.DLL
Summary: crash by recursive document writes of script → crash by recursive document writes of script
Whiteboard: TB27672913M
Severity: normal → critical
Yeah, Mozilla blows out the stack with code like that. This might be a dupe, though I have no idea what the original bug would look like...
We really should try to do something about this... perhaps arbitrarily limit script execution nesting depth to some sane value (say 200)?
Whiteboard: TB27672913M → TB27672913M, DUPEME
could we somehow do this in a more generic way then putting a limit inside nsHTMLScriptElement? Bug 185092 is the same basic problem just a different recursion. Js-code calls native code which code which calls js-code again. IIRC the js-engine has a recursion limit that protects against js recursion to death. Are we getting around this cap when we recurse through native code? If so, could the code for that cap be modified so that it takes this senario into account? Or is the problem simply that the cap is too low for this senario and each recursion ends up eating so much stackspace since we're calling through so many different objects at each recursion. If so the solution won't be quite as easy i'm afraid, though still not impossible.
See bug 220408 -- someone should really fix that, then test all the bugs filed on "stack overflow" and "recursion" (search for those words as keywords in their summaries), marking DUPs and WFMs as appropriate. /be
If there are native code paths that can overflow the stack even after the JS_SetThreadStackLimit API call has been introduced, those will need to do their own ad-hoc depth vs. limit checks. Bugs would have to be filed against each offending component. /be
Whiteboard: TB27672913M, DUPEME → DUPEME
This still hangs Firefox 1.0.2 (win2k sp4) and FF 20050407 & 2005040606 (XP & win2k sp4) trunk builds. What needs to be done to kill this bug?
also Seamonkey Trunk on Windows 2000 SP 4 and XP SP2 hangs
> What needs to be done to kill this bug? Deciding what the right behavior is (and why).
Why isn't this cought by the generic stack limit placed on js-code these days? I.e. why wasn't this fixed by bug 220408?
Assignee: general → nobody
QA Contact: ian → general
WFM. Instead of a crash, I get a bunch of: Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMHTMLDocument.write]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: https://bug229035.bugzilla.mozilla.org/attachment.cgi?id=137746 :: <TOP_LEVEL> :: line 10" data: no] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090912 Minefield/3.7a1pre I bet this was fixed the same way as bug 400792, since the testcases are very similar.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: