Closed
Bug 229035
Opened 22 years ago
Closed 16 years ago
crash by recursive document writes of script
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 400792
People
(Reporter: bc, Unassigned)
Details
(Keywords: crash)
Attachments
(1 file)
223 bytes,
text/html
|
Details |
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.
Reporter | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
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
Updated•22 years ago
|
Severity: normal → critical
Comment 3•22 years ago
|
||
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...
![]() |
||
Comment 4•22 years ago
|
||
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.
Comment 6•22 years ago
|
||
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
Comment 7•22 years ago
|
||
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
Updated•21 years ago
|
Whiteboard: TB27672913M, DUPEME → DUPEME
Comment 8•20 years ago
|
||
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?
Comment 9•20 years ago
|
||
also Seamonkey Trunk on Windows 2000 SP 4 and XP SP2 hangs
![]() |
||
Comment 10•20 years ago
|
||
> 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?
Updated•16 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 12•16 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•