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)

defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: jruderman, Assigned: jst)

Details

(Keywords: hang)

Attachments

(1 file)

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.
Attached file test case
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
and related to bug 56940
See also bug 70821, memory limit per window.
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
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
Keywords: hang
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?
Once again, once UBound=25 or so, I start running out of memory on my WinNT box (128M RAM).
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.
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
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.
OK, I will mark "WORKSFORME" based on Jesse's comments -
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Resolving as WORKSFORME -
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
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.

Attachment

General

Creator:
Created:
Updated:
Size: