Open
Bug 673264
Opened 13 years ago
Updated 2 years ago
browser crash while running javascript with multiline string literal
Categories
(Firefox :: General, defect)
Tracking
()
REOPENED
People
(Reporter: pavlocherkashyn, Unassigned)
References
Details
(Keywords: crash, testcase, Whiteboard: [sg:dos oom])
Crash Data
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30 Steps to reproduce: I am developing/testing my own script which is not in the internet yet. Actual results: total browser crash. crash details are here http://crash-stats.mozilla.com/report/index/bp-54c7de33-6baf-4f37-834e-f9d732110721 Note: the same bug is in Chrome and IE Expected results: 1 option one: only one tab should crash is this is syntax mistake 2 option two: javascript exception if parsing is fine, but something is wrong in javascript
Updated•13 years ago
|
Crash Signature: [@ PL_DHashTableOperate ]
Updated•13 years ago
|
Attachment #547534 -
Attachment mime type: application/octet-stream → application/zip
Comment 2•13 years ago
|
||
Comment 3•13 years ago
|
||
The script creates an deep tree of HTML table elements, using innerHTML. I do get an "Unresponsive Script" warning dialog and if I click Stop I can then close the tab and no harm is done. If I click Continue it eventually runs out of memory. So this looks like a bug we're already well aware of.
Whiteboard: [sg:dos oom]
Updated•13 years ago
|
Attachment #547534 -
Attachment mime type: application/zip → application/java-archive
Comment 4•13 years ago
|
||
How does this become recursive? There's only one <div> in the html to start with and the innerHTML that adds more isn't called until the getElementsByTagName list is already returned.
Comment 5•13 years ago
|
||
The collection returned by getElementsByTagName is a /live/ collection, see: https://developer.mozilla.org/en/DOM/element.getElementsByTagName http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#collections-0 so when this loops inserts new <div>s the become part of what you're looping over. Here's value of document.body.innerHTML for the first few iterations. I printed the values of 'i' and 'doc.length' as well.
Reporter | ||
Comment 6•13 years ago
|
||
couple more comments: in lines -------- <div id="'+boxId+'-but-fb" class="bb-box-but-32x32 bb-box-but-fb" \ <div id="'+boxId+'-but-tweet" class="bb-box-but-32x32 bb-box-but-tweet" \ <div id="'+boxId+'-but-in" class="bb-box-but-32x32 bb-box-but-in" \ -------- if i skip '+boxId+' and rewrite like these lines below - it works fine. -------- <div id="but-fb" class="bb-box-but-32x32 bb-box-but-fb" \ <div id="but-tweet" class="bb-box-but-32x32 bb-box-but-tweet" \ <div id="but-in" class="bb-box-but-32x32 bb-box-but-in" \ -------- the same happens id i use plain javascript to insert dom elements - it crushes when i try to set element id equal to boxId + '-smth'.
Updated•12 years ago
|
Comment 7•6 years ago
|
||
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Reopening because crash bugs **with testcases** should not be resolved **as WONTFIX** based on queries of crash-stats. Other resolutions may be appropriate for other reasons. (Crash signatures are not the same as bug identity; they're merely a search aid to find and group similar crashes. The bug may still be present, but the signature may have changed slightly, or the bug may even still be present with the same signature but there are simply no recent reports of crashes in that function.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•