285951 - firefox begin to eat memory and hangs after opening this URL

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Maxim Shpakov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.6) Gecko/20050223 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.6) Gecko/20050223 Firefox/1.0

After loading http://allweb-search.ru/ Firefox begins to eat memory and hangs
all the open windows of FF

Reproducible: Always

Steps to Reproduce:
1.Open URL http://allweb-search.ru/
2.Wait while it loading.
3.Whatch Taskmanager for FF memory allocation :)

Actual Results:  
Firefox hangs and eat nearly 300 mb and growing in 1 minute

Expected Results:  
Show page normally

WinXP SP2
FF 1.0.1 Russian + TabMix extension

Comment 1

[Maxim Shpakov]

I've searched talkback site for this URL and found some talkback ids

4 - allweb-search.ru
http://allweb-search.ru
0x014a4cb0
4085667 	Loading of Tabgroup default setting is appending
0x0223d63c
4085788 	loading of tabgroup freh booted windows fresh started Mozilla.
DummyLayoutRequestEvent::HandleEvent
4085332 	started Mozilla load Groupmark preference set to appending. groupmark:
https http http Buglist Tinderbox bonsai
4063446 	Bug 284368 when going to this website with FF1.0 it slowly increases
both RAM and CPU loading the page above was hanging Mozilla or crashing Windows
twice talkback came up after rebooting Windows and starting Mozilla


But I can't reproduce Firefox crashes.. it simple hangs.. 

Comment 2

[Maxim Shpakov]

May be this is a duplicate of 
https://bugzilla.mozilla.org/show_bug.cgi?id=284368

But seems that it is not fixed.

Comment 3

[David Tenser [:djst]]

Confirming on Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.7.5) Gecko/20050221
Firefox/1.0 (Ubuntu) (Ubuntu package 1.0+dfsg.1-6ubuntu1).

The browser seems to allocate memory to a point where it simply closes without
leaving any error message or crash data.

Bug 228829 could be related.

Comment 4

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050323
Firefox/1.0+

Attempting to reproduce with latest nightly.  Looks to me like it /does/ indeed
start to suck up some insane CPU.  Holds steady at firefox.exe taking 99% of the
CPU on my laptop when on that site, even after it is 'finished' loading.  I
didn't see the RAM usage rise any however.

Wasn't this supposedly fixed by bug 228829 ?

CCed myself

Comment 5

[Grey Hodge (jX)]

First, I'm duping this to bug 284368, and then asking on bug 228829 what's
happening, why testers are still seeing this.

*** This bug has been marked as a duplicate of 284368 ***

Comment 6

[Grey Hodge (jX)]

I'm evil and stupid, duped to wrong bug... Ignore the bugspam while I dupe to
bug 228829

Comment 7

[Grey Hodge (jX)]

*** This bug has been marked as a duplicate of 228829 ***

Comment 8

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050323
Firefox/1.0.2

Latest Aviary build, reproduces exactly as described, up to 99% RAM as before on
the latest-trunk, per my comment #4, but also sucked down almost 200MB of RAM
before I killed the process.  That was a spike from using ~20MB right before
opening the link.

Freaky.

Comment 9

[Boris Zbarsky [:bzbarsky]]

So.. if this bug is clearly different from bug 228829 (obviously, since it
wasn't fixed by the same patch), why was it marked duplicate?

This page doesn't really have recursive iframes.  It has iframes referencing
other pages that reference still other pages, etc.  Not really very recursive,
with a very large branching factor.  That's not what bug 228829 was about at all.

This page _may_ be helped by bug 285395, though.

Comment 10

[Grey Hodge (jX)]

My bad then, I didn't see the iframes being closed before the next opened.

Comment 11

[Wayne Mery (:wsmwk)]

website must have changed. I don't see this.  Do you?

Comment 12

[Grey Hodge (jX)]

Yep, this is now a domain parking page, so WFM.