Closed
Bug 40391
Opened 25 years ago
Closed 23 years ago
js + on long strings freezes mozilla, horks win98
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
WORKSFORME
Future
People
(Reporter: jruderman, Assigned: jst)
Details
(Keywords: hang)
Attachments
(1 file)
292 bytes,
text/html
|
Details |
the testcase shows what happens when you try to concatenate strings that are
rediculously long using javascript. The browser hangs, and on my windows 98
system (128 megs of ram, 400 mhz), the hard drive thrashes a whole lot. A
single + command can hang mozilla and slow the OS for a minute. internet
explorer has this bug too.
this bug is similar to bug 34571 in that it involves string concatenation
slowness. bug 34571 is a performance bug; this is a security-against-crashing
bug. bug 32334 is also related because it deals with long strings.
suggested fix: limit how much memory a window (not a webshell) can use, and
implement bug 30942 in a way that includes string manipulation functions.
Reporter | ||
Comment 1•25 years ago
|
||
Comment 2•25 years ago
|
||
Phil, another memory hog to try reproducing. If it doesn't crash we can just
move it to [Future] and/or dupe it to the bugs mentioned in the report.
Assignee: rogerl → pschwartau
Comment 3•24 years ago
|
||
Related to bug <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=31926">bug
31926</A>?
Comment 6•24 years ago
|
||
First, I would like to apologize to Jesse and everyone for taking
so long to get to this. It's something I totally lost track of: sorry!
I've been running this version of Jesse's testcase in the optimized
standalone JS shell:
var str = 'a';
var UBound = 25;
for (var i = 0; i<UBound; i++)
{
str += str;
}
I have a WinNT box with 128M of RAM. I make it through the test
if I set UBound=25 above, but I run out of memory if I set UBound=26.
I get this message from the JS shell: "Out of memory".
I don't know whether to interpret this as a failure of the JS Engine.
Clearly one could set UBound higher and higher: do we expect NEVER to
run out of memory no matter how big the strings get? If not, what value
of UBound do we expect my WinNT box to handle?
As for some of the related JS Engine bugs mentioned above, note I
recently resolved as WORKSFORME bug 31926:
"for() loops significantly slower than MSIE"
Meanwhile, Brendan is currently working on bug 56940:
"O(n**2) and O(n**3) growth too easy with JS string concat"
However, I don't see this bug as a duplicate of these JS Engine bugs.
If I understand Jesse correctly, his suggested solutions refer to actions
the browser could take to prevent memory from being exhausted.
Therefore, I'd like to send this one to the DOM for their consideration.
And again, my apologies for not getting to this one before this. I don't
do that very often, and I feel badly about it -
If people feel this is specifically a JS Engine issue, then this bug
should probably be duped against bug 56940.
Assignee: pschwartau → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale
Assignee | ||
Comment 7•24 years ago
|
||
This is hardly a critical bug. It's one more of those "don't do that then" bugs :-)
I don't have any time available for woking on this any time soon so I'm pushing
this to Future for now.
Severity: critical → normal
OS: Windows 98 → All
Hardware: PC → All
Target Milestone: --- → Future
Comment 8•23 years ago
|
||
Now that bug 56940 is fixed, things are probably a lot better. Can we do some
new tests to know if the situation is acceptable?
Comment 9•23 years ago
|
||
Once again, once UBound=25 or so, I start running out of memory
on my WinNT box (128M RAM).
Assignee | ||
Comment 10•23 years ago
|
||
Phil, is there still something that should be done about this? If so, please
re-assign to the appropriate JS engine developer, or mark as fixed, or dup, or
whatever. I don't see the DOM doing anything bad here.
Comment 11•23 years ago
|
||
The main issue in this bug is what action the browser could take to prevent
memory from being exhausted when JS is pushing it to the limit. As we
discussed recently, this is a problem beyond the DOM component alone.
If Jesse doesn't mind, I will reluctantly mark this as WONTFIX.
The point raised here is well-taken, but in my disussions with developers
about memory exhaustion issues, it appears that the problem is too general
for a fix right now. That is, I have been told there are too many places
in the browser code where memory-checks are not what they could be...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 12•23 years ago
|
||
I also get an "out of memory" error in the javascript console when I try to go
beyond 2^25 chars (32MB), on Win98 with 128 MB RAM. I think that's reasonable,
because if you tried to make larger strings, each concat would take too long
(longer than the time it should take for a "this script has been running at
100% cpu for a while, do you want to stop it?" dialog to appear or for the
browser to react to me trying to close the window.).
I'd actually consider this WFM, since when I originally reported this bug, the
last few concats would take up to a minute and prevent me from using the
computer at all.
Comment 13•23 years ago
|
||
OK, I will mark "WORKSFORME" based on Jesse's comments -
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 14•23 years ago
|
||
Resolving as WORKSFORME -
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 15•23 years ago
|
||
And Verified - Jesse, thanks for your patience on this one!
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•