js + on long strings freezes mozilla, horks win98




19 years ago
17 years ago


(Reporter: jruderman, Assigned: jst)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



19 years ago
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.

Comment 1

19 years ago
Created attachment 9053 [details]
test case

Comment 2

19 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 4

18 years ago
and related to bug 56940

Comment 5

18 years ago
See also bug 70821, memory limit per window.

Comment 6

18 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

Comment 7

18 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


18 years ago
Keywords: hang

Comment 8

17 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

17 years ago
Once again, once UBound=25 or so, I start running out of memory
on my WinNT box (128M RAM). 

Comment 10

17 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

17 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...
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 12

17 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

17 years ago
OK, I will mark "WORKSFORME" based on Jesse's comments - 
Resolution: WONTFIX → ---

Comment 14

17 years ago
Resolving as WORKSFORME -
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 15

17 years ago
And Verified - Jesse, thanks for your patience on this one!
You need to log in before you can comment on or make changes to this bug.