227849 - Large external JavaScript case statment crashes browser

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[aaron spuler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

The page
http://www.cs.swt.edu/~as1130/temp/broken/Sunshine%20State%20Vehicle%20Registration.htm
crashes Mozilla 1.2, Mozilla 1.5, Firebird 0.7 and Firebird nightly builds, for
example (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031130
Firebird/0.7+. But this page does not crash Internet Explorer on the same machine.

Reproducible: Always

Steps to Reproduce:
1.Navigate to
http://www.cs.swt.edu/~as1130/temp/broken/Sunshine%20State%20Vehicle%20Registration.htm
2.Browser will hang, and then crash.

Actual Results:  
Browser crashes.

Expected Results:  
Load page.

Bug occurs regardless of theme installed.  There is no module reported for the
crash -- I had to manually kill the application myself each time.  Modifying the
external JavaScript file to use an array instead of a case statement fixes the
problem.  The external JavaScript file holds all United States Zip codes and
their corresponding cities.  This topic has been discussed at
http://forums.mozillazine.org/viewtopic.php?t=38869, along with modified
Javascript files to make it work in Gecko browsers.

Comment 1

[aaron spuler]

Attachment: testcase that crashes mozilla

This is a zip archive of the three files (1 htm and 2 javascript) that do not
work in Mozilla.  For ease of reference, these are the same files as indicated
at the url in the description.

Comment 2

[aaron spuler]

Attachment: testcase that works with mozilla

This is a zip archive of the testcase that does work in mozilla.  
Note:
*there are no changes to the htm file
*the pinfo1a.js file only has one change: line 150 changed from
fillcitystate(eval(element.value)); to fillcitystate(element.value);
*the file that was modified by Tom Hatta ([e-mail])is zipcode.js

Comment 3

[Gérard Talbot]

The provided testcase that supposedly crashes Mozilla is definitively not a
REDUCED testcase. 
zipcode.js size is 2,031,375 bytes. 
Reporter, can you create a reduced testcase enlightening the bug?

Comment 4

[aaron spuler]

I don't know that I can... As far as I can tell, it was the enlarged size of the
javascript file that crashed the browser...  I lost the files when my
university's server crashed (it was put up after their most recent backup).  So
I don't have a copy to reproduce the problem any more.

I'm sorry.

Comment 5

[Martijn Wargers (dead)]

Attachment: A reduced testcase (no crasher, just a bit slow)

Well, I made the original testcase shorter. 
This does not freeze the browser permanently, but I guess this shows that with
the more switch cases the browser takes longer to 'js parse' them.
Internet Explorer is just a lot faster with the switch cases.

Comment 6

[Asa Dotzler [:asa]]

unable to reproduce any crash. CPU usage spikes but no crah for me with winXP
and mozilla 1.7 beta

Comment 7

[Alfonso Martinez]

No crash with w98 and 1.7b.
Mozilla was freezed while it loaded the first testcase, but didn't crash

Comment 8

[Alex Vincent [:WeirdAl]]

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040405
Based on other comments, marking WORKSFORME.  Reporter:  would you do a quick
search for perf-related bugs in JSENG relating to the switch and case
statements?  You may want to open a new bug, minus the crash keyword, for this
if you don't find one.  Or, you may want to reopen this one, resummarize, and
remove the crash keyword.

Comment 9

[Alex Vincent [:WeirdAl]]

Note:  I did let the first testcase run for ten minutes (the one labeled
crasher); it did apparently hang Mozilla, but I have something else running in
the background as well, which may have skewed results.

Comment 10

[Brendan Eich [:brendan]]

Without a stack, it's impossible to say what the bug might have been.  If anyone
does get a crash, even with an old build, I'd love to see the stack and local
memory/register contents.

/be