Closed
Bug 334935
Opened 19 years ago
Closed 18 years ago
Array: methods on a long array cause system to hang (DOS)
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: BijuMailList, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
fix for bug 330812 solved DOS when Array(1 << 29).sort();
but other issues remained.
* unable to catch in try{} catch(e){} block
* Array also have other methods which give prob.
steps to test
1. open long_array_dos.html
2. click Input Case : 0 link
3. click test button
4. repeat for all
BTW: Even though I am not good in CS, just a question.
For arrays having most elements empty,
why cant we have an algorithm similar to one processing sparse metrics and save memory and processing time?
depends on bugs
bug# 101964, - Performance: truncating arrays is slow in SpiderMonkey
bug# 171262, - Performance: improve speed of new Array creation
bug# 253325, - Array.join() on long array hangs browser for unreasonably long time
bug# 310405, - Unstoppable too long execution with Array.forEach
bug# 322135, - calling push method on array with maximum length (2^32-1 = 4294967295) causes Spidermonkey to run out of memory
bug# 322889, - Array implementation should specialize its own nearly-native JSObjectOps
related
bug# 253138, - Array.prototype.toSource excludes non-indexed enumerable properties
bug# 260106, - elisions in array literals should not be enumed
dist related
bug# 200505, - Optimization of jsref array_join_sub() function
bug# 224128, - Array.sort isn't a stable sort
Comment 3•18 years ago
|
||
The patch for bug 310405 addresses this.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 4•18 years ago
|
||
Removal of performance-related blockers as fixing DOS issues does not require optimized array implementation.
You need to log in
before you can comment on or make changes to this bug.
Description
•