311807 - System will consume all memory and thrash disc in just a few minutes -

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051008 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051008 Firefox/1.4.1

When visiting the site listed in the URL with javascript 'enabled', the page
never loads and the machine will begin to thrash the disc, and consume memory
and virtual memory until you lock up or kill the process via Task Manager,
whichever your patience allows. 

Reproducible: Always

Steps to Reproduce:
1. visit the URL 
2. note the machine memory going up by leaps
3. Kill the Process with Task Manager - to regain control of your system 

Actual Results:  
Should not freeze up the system and consume memory due to javascript running out
of control. 

Expected Results:  
Stopped the bad script or raised the warning about javascript causing machine to
run slow?  Best would be to terminate the script. 

Been reported to occur in 1.0.7 as well. 
Forum thread: http://forums.mozillazine.org/viewtopic.php?t=327910

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Testcase from that site.
I'm seeing this bug also in current trunk build.

Comment 2

[Brendan Eich [:brendan]]

DOS attacks don't block releases, there are way too many, not all require JS, etc.

Given the while loop, you should get a "slow script" dialog eventually.  If you
don't have enough RAM, it might not be able to come up (we don't preallocate all
the memory needed for it, or for OOM reports -- ouch).

Unless there is a regular expression bug hiding here, this is not a 1.8 blocker.
There are large families of regular expressions that make JS regexp execution
time expontentially explosive (same for Perl4, and probably for some cases where
Perl5 didn't add short circuiting).

We should ensure that with enough RAM, the slow-script dialog fires when it should.

/be

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

Brendan when I was watching the TaskManager it did not take long for 1.5B2 to
run up all the memory in RAM, then RAM usage dropped to like 30 meg, but the
disk was going crazy swapping out stuff and went to 980Meg before I killed the
process, so I assume if left running 'unchecked' it would comsume all available
space on disk and never fire the 'slow script warning'..

Comment 4

[Bob Clary [:bc] (inactive)]

I don't get the slow script warning in 1.5b2+/winxp but the testcase completes
relatively quickly with an out of memory error after eating about 1200K of RAM
after which the usage falls to about 800K.

Comment 5

[Kris Maglione [:kmag]]

I get this on: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10)
Gecko/20050721 Firefox/1.0.6

This is a separate issue from a slow script warnings. This script will keep
eating memory until the system runs out. This shouldn't be allowed... it can
actually bring down a poorly configured system.

Comment 6

[Vaughn L. Reid III]

I think I'm experiencing a similar bug to the one described here.  I went to the Indiana Professional licensing agency search page:

https://extranet.in.gov/WebLookup/Search.aspx?facility=N

and ran a search for all licensed detectives without selecting any additional options.  Upon submitting my search, the computer immediately began running slow.  I checked task manager, and it showed that firefox was using 99 percent of CPU time and about 1/2 of my system's ram.  As I waited for the search results to come back, the system became even slower.  At this point, I noticed that the search had completed.  I then tried to scroll up and down to see results, but, at that point the system became unresponsive.  I then used task manager to kill firefox.exe and system operation returned to normal.  Here the particulars of my Operating System and Firefox version.

Operating System
Windows 2000 Professional with Service Pack 4

Firefox Version
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Comment 7

[Carolyn Scheppner]

I have had this or a similar problem under both XP and Windows 2000 (upgrade over NT).

I can't pin it down.  It sometimes happens when I leave a few Firefox windows open for an hour or more, and usually one of the windows is looking at a some site cluttered with graphics, or with an animated ad, or maybe heavy scripting (i.e not just 3 windows searching Google).  I have the Firefox cache enabled and a cache memory limit set (a limit which is ignored).

This problem started happening for me with Firefox 1.5.

Carolyn

Comment 8

[Martijn Wargers (dead)]

Carolyn, that's a different issue. This is something what you get when you visit the url or the testcase.

Comment 9

[erkinbah]

I observed a similar situation upon visiting this URL:

http://prdownloads.sourceforge.net/xmule/xmule-1.13.6.x86-gcc33.package

It sucks up all the memory and the swap really fast (in a few seconds). And I can't use the computer unless I kill firefox-bin.

Very consistent bug, I can reproduce it every time I open this url.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060314 Ubuntu/dapper Firefox/1.5.0.1

Comment 10

[Lucius Chiaraviglio]

(In reply to comment #9)
> I observed a similar situation upon visiting this URL:
> 
> http://prdownloads.sourceforge.net/xmule/xmule-1.13.6.x86-gcc33.package
> 
> It sucks up all the memory and the swap really fast (in a few seconds). And I
> can't use the computer unless I kill firefox-bin.

I tried this under Windows XP SP2.  The above link did not do anything abnormal,
but when I went to one of the links listed on the page (the Minnesota site),
Firefox attempted to display the file instead of downloading it.  After loading
about 3/4 of the file onto the screen, it did indeed become extremely slow
(responding to menu pull-downs and updating its screen probably less than once
per minute) for several minutes while the system memory usage meandered between
300 Mib and 320 Mib (Task Manager said that firefox.exe was using somewhat over
30 Mib, as opposed to somewhat over 20 Mib right now).  The rest of Windows XP
functioned almost normally (although I am pretty sure it would have clogged up
if my computer had much less than 512 Mib of physical RAM), with the window
manager even responding promptly to a click on the icon at the upper left
corner of the Firefox window, and other applications (tried Word and
Thunderbird) working at almost normal speeds.  Windows did have a bit of
trouble getting rid of partially-displayed Firefox menus from on top of other
applications, and did exhibit a weird bug that after a while caused the
Firefox window to get grouped with Windows Explorer in the Task Bar.  After
several minutes (did not time it, but estimate between 10 and 15), Firefox
finally finished loading the page and started working normally, including a
new Firefox window being listed as such in the Task Bar (this didn't fix the
one that was already grouped with Windows Explorer).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Has Adblock and NoScript, but I told NoScript to permit JavaScript on the
relevant 2 sites.

Comment 11

[tech]

Here's a link with only one animated gif, when loading it, just after starting firefox v 1.5.0.1
the firefox memory use grows quickly(up to 700 Mo) using nearly all processor ressource (between 60 and 100 %) I must precise that the actual size of the picture is "only" 2,3 Mo and it's the only thing loaded after starting firefox, so there's no javascript involved. 

the link : http://facs.scripps.edu/surf/images/euranim.gif

Comment 12

[Phil Ringnalda (:philor)]

Looks like this was accidently re-moved to Firefox; re-re-moving.

Comment 13

[tech]

Still got this problem with firefox v 1.5.0.4

Comment 14

[Feng Qian (Google)]

The testcase is wrong:

temp += val.substr(arr.lastIndex, val.length);

It should be "re.lastIndex". 

(In reply to comment #1)
> Created an attachment (id=199022) [edit]
> testcase
> 
> Testcase from that site.
> I'm seeing this bug also in current trunk build.

Comment 15

[Feng Qian (Google)]

Attachment: corrected testcase

FF works fine with this testcase. In previous testcase, SpiderMonkey throws OOM exception.

Comment 16

[Bob Clary [:bc] (inactive)]

(In reply to comment #15)

IE adds a lastIndex property to the captures array. The cause of the problem here is an infinite loop in Firefox since the condition while ((arr = re.exec(val)) != null) never fails since s.substr(undefined, s.length) == s

This is really Tech Evangelism, but we shouldn't lock up either.

Comment 17

[Cees T.]

Bug 326225 has a patch that may catch excessive memory usage.

Comment 18

[Brian Crowder]

Pretty sure this is fixed by one of several recent patches to jsregexp.c, just not sure which one.