258954 - sonystyle.com.cn - Mozilla/Firefox/Galeon/Epiphany... crash

Status: RESOLVED WONTFIX

(Tech Evangelism Graveyard :: Chinese-Simplified, defect)

Description

[Qiu Yingbo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

I test it on linux and Windows platform, I use firefox/galeon/epiphany in linux and
firefox/mozilla/netscape in windows. 

maybe a gecko's bug

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
the program freeze. and the OS begin swap memory -- HD's LED begin twinkling.
windows will report VM too low.

Comment 1

[Andrew Schultz]

the page loads a script http://www.sonystyle.com.cn/iemenu.js, which is 182Kb on
one line.  Mozilla gets bogged down just loading the script.  A html page with
some javascript from the URL to set up the menus and including the iemenu.js
fluctuated between 110 and 330MB of memory usage (I have 512MB total), but did
eventually load.  Loading the full page was similar.

Over to JSEng in case there is anything that can be done to improve handling of
such an enormous script.  If not, this is probably INVALID.

Comment 2

[Boris Zbarsky [:bzbarsky]]

We had a bug for long one-line scripts already... Didn't brendan check in a fix
for that?  If so, is this a problem in builds with said fix?

Comment 3

[Nicholas Allen]

bug 218511

You filed a followup bug that it was still slow though.

Comment 4

[Brendan Eich [:brendan]]

The bug 236272 that bz filed as a followup to bug 218511 is about the HTML
parser, though, and that code won't be run when dealing with an out-of-line script.

Reporter says this was in Firefox 0.9, and the patch for bug 218511 was in 0.9,
so I'll take a look at this using the js shell.

/be

Comment 5

[Brendan Eich [:brendan]]

Not a JS engine bug, AFAICT:

[~/src/phoenix/mozilla/js/src2]$ Linux_All_OPT.OBJ/js < ~/iemenu.js
1: ReferenceError: Image is not defined
[~/src/phoenix/mozilla/js/src2]$ time !!
time Linux_All_OPT.OBJ/js < ~/iemenu.js
1: ReferenceError: Image is not defined
                                                                                
real    0m0.084s
user    0m0.080s
sys     0m0.000s
[~/src/phoenix/mozilla/js/src2]$ time Linux_All_OPT.OBJ/js < ~/iemenu.js
1: ReferenceError: Image is not defined
                                                                                
real    0m0.092s
user    0m0.080s
sys     0m0.010s
[~/src/phoenix/mozilla/js/src2]$ time Linux_All_OPT.OBJ/js < ~/iemenu.js
1: ReferenceError: Image is not defined
                                                                                
real    0m0.084s
user    0m0.080s
sys     0m0.000s
[~/src/phoenix/mozilla/js/src2]$

So the js shell loads this quickly, using stdio.  If there's some big lag, it
must be somewhere above the JavaScript Engine layer, either in the script loader
or in Necko.  Bouncing to the HTML content code.  bz, do you have time to do a
profile?

/be

Comment 6

[Boris Zbarsky [:bzbarsky]]

Profiling doesn't help so much.  I can't load the page altogether because it
runs out of memory and dies (I have 768 MB or RAM and 256 MB of swap).  The flat
profile looks like:

Total hit count: 75448
Count %Total  Function Name
36779   48.7     str_indexOf
26697   35.4     memcpy
2487   3.3     __libc_calloc
887   1.2     mmap
799   1.1     munmap
456   0.6     posix_memalign

So we're just moving massive amounts of memory around and working with some huge
string.

At a guess, the script assumes something IE-specific and does something totally
wrong in Mozilla...  someone would need to reduce the script to the part that
actually blows up in memory.

Comment 7

[Andrew Schultz]

> At a guess, the script assumes something IE-specific and does something totally
> wrong in Mozilla...

you couldn't be more right.  the problem is my old nemisis "xrep".  see bug
164173.  at sonystyle, the string of interest is 128K (instead of 27K in bug
164173).  attachment 96795 [details] is the reformatted javascript from that bug (also
named iemenus.js)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ah, yes.  And see also bug 161633 (which has similar analysis that I did at some
point on yet another xrep-using site).

bc, could we contact the providers of this iemenu.js code?  Any idea who they are?

Comment 9

[Brendan Eich [:brendan]]

Who wrote that garbage?  Yeesh.

/be

Comment 10

[Bob Clary [:bc] (inactive)]

I believe they are using a really early version of
<http://software.xfx.net/utilities/dmbuilder/index.htm>. For example, at
<http://software.xfx.net/utilities/dmbuilder/webslist.htm?s=20&order=0&condensed=0>
look at adminpower.com which is using a 2.8 version.

Newer versions support us better I think.

Comment 11

[Qiu Yingbo]

Thanks for your discussion. I believe that the code is garbage, but the garbage
code should not crash my browser.... :(

I am a unix C programmer with 6 years experience. Maybe I can do something for the
bug. please give me some advice.

Comment 12

[timeless]

reporter: if this is only hanging then there's not much I could suggest. there
is some tuning that can be done for slow scripts (we're probably going to donate
some improved error reporting for them).

at some point gecko may be rewritten so that each docshell gets its own thread
and the ui threads would be able to survive and ignore stupid web pages. this
isn't going to happen anytime soon, if you want to help with such an effort you
could start by learning layout (just learning it will take at least a month). if
you're really interested in helping, someone cc'd to this bug would be glad to
give you much smaller and more reasonable tasks which you could work on.

Comment 13

[Qiu Yingbo]

I review the mozilla source code and find mozilla has implemented `join'
function in js/src/jsarray.c now.

In the period of loading sonystyle's homepage, mozilla call str_split 
and array_join function 5097 times. is that a garbage collection issue?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Mozilla has always had join() implemented.

The core issue is that the site just does something that allocates a huge chunk
of memory (unless your browser is IE, in which case it does something
different).... We _may_ be able to GC more aggressively here, but even that may
not help enough because the site is creating a whole bunch of (large) temporary
objects all at once.

Comment 15

[timeless]

no, the joins and splits are things that the code is asking for. i'm not going
to spend time pointing our where.

Comment 16

[Nicholas Allen]

If anything, the GC already tends to be over-aggressive in these cases.  The
rooted object graph is fairly large and so there's a significant static cost to
running a GC.  Lots of bloaty string manipulation can kick off a GC, causing a
full sweep to be done every few allocations.  It's generally better to let the
working set grow a little (depending on your physical memory) to amortize the GC
costs.

Comment 17

[Felix Miata]

Conforming summary to TFM item 10 at 
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new

Reporter, when you file a TE bug, please follow the reporting guidelines.

Comment 18

[Charles Fenwick]

*** Bug 272756 has been marked as a duplicate of this bug. ***

Comment 19

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041202
Firefox/1.0+

I came here from Bug 272756.

The page eventually loaded but was very slow - tens of minutes.

No crash

Comment 20

[Kevin Brosnan]

*** Bug 273976 has been marked as a duplicate of this bug. ***

Comment 21

[Qiu Yingbo]

I think sonystyle.com.cn have rewrite their homepage