657010 - High heap-unclassified on some sites

Status: VERIFIED WORKSFORME

(Core :: General, defect)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/message/reply/question/etc.)]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110512 Firefox/6.0a1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:6.0a1) Gecko/20110512 Firefox/6.0a1

 

Reproducible: Always

Steps to Reproduce:
1. Go to http://jailbaitgallery.com/search.php?q=Kairi+&search=Search (care, it's NSFW !!!)
2. open about 5 tabs with photos in background with keyboard shortcut CTRL+C
3. see what happens in Task Manager, one core is eaten 100% also memory usage is dramatically growing and browses is unusable because of hanging

Comment 1

[TinyButStrong]

Bug confirmed, 2.5gb of ram and growing...

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110513 Firefox/6.0a1

Comment 2

[Thomas Ahlblom]

Major problems with GNU/Linux as well.
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110513 Firefox/6.0a1

Comment 3

[Matthias Versen [:Matti]]

I get 100% CPU on one core and steady growing memory usage with Opera11 (but less than FF).
This looks like a bug in the page
Anyone who wants to test this with webkit ?

Comment 4

[Thomas Ahlblom]

Heavy load on two cores and eats memory. Can't even open 5 tabs with photos. After a while I get a Page(s) Unresponsive pop-up.
Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16

Comment 5

[Matthias Versen [:Matti]]

Thanks Thomas, my system is webkit free :-)
marking invalid due to bug in the page

Comment 6

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/message/reply/question/etc.)]

Maybe bug on the page, but shouldn't Firefox prevent yourself from hanging and eating that much memory?
This can lead in some way to system crash due to memory overload and IIRC Firefox has problems with it.

Don't forget that WebKit and Opera can be also bugged ;p

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/message/reply/question/etc.)]

So no protection sites like this will be in Fx ?

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/message/reply/question/etc.)]

Reopening, site action shouldn't hang Firefox. Protection for memory eating sites is also needed

Comment 9

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/message/reply/question/etc.)]

Bumping because it still happen on Firefox 12.0a1pre
Can someone look into this, because it's still marked as unconfirmed and I don't think that any browser should behave that way with

Comment 10

[Nickolay_Ponomarev]

Well, if you have lots of memory, you'll get the Unresponsive script dialog, from which you can stop the misbehaving script and close the tab to reclaim much of the memory, which is:

1,217.86 MB (100.0%) -- explicit
├────608.91 MB (50.00%) ── heap-unclassified
├────564.43 MB (46.35%) -- window-objects
│    ├──560.18 MB (46.00%) -- top(http://jailbaitgallery.com/index.php?id=17411, id=59)
│    │  └──560.18 MB (46.00%) -- active
│    │     ├──559.91 MB (45.98%) -- window(http://jailbaitgallery.com/index.php?id=17411)
│    │     │  ├──308.64 MB (25.34%) ── dom [2]
│    │     │  ├──251.25 MB (20.63%) -- layout
│    │     │  │  ├──251.10 MB (20.62%) ── arenas

I see two things that could be fixed here:
1) Firefox could warn you if a page allocates more than X MB of memory, just like it warns about unresponsive script (couldn't find an existing bug about that, wierd!)
2) if you manage to close the offending tab, not all memory is reclaimed, I see around 250 MB heap-unclassified after clicking minimize memory use a few times.

The general solution for misbehaving sites is "electrolysis" (running sites in a separate process), the project was put on hold for now.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Hmm.  I wonder what that heap-unclassified is made of....

Comment 12

[Justin Lebar (not reading bugmail)]

Holy crap.

93% heap-unclassified.

7s CC times.  And it doesn't go away, even after I close the tabs!

Comment 13

[Justin Lebar (not reading bugmail)]

8m refcounted nodes, 25k GC'ed nodes.  GC times are fast (less than 100ms).

Comment 14

[Justin Lebar (not reading bugmail)]

So there are two separate issues here.

One is the heap-unclassified.  I took a CC dump; it's too big to post to bugzilla, but I'll give it to Andrew.

The other is the fact that, in one instance, the compartment leaked, and we had 8m refcounted nodes permanently sitting around.  I think the latter issue may be due to an extension.  But the only extensions I'm running are ABP and Test Pilot, so that's worrying too.

Comment 15

[Justin Lebar (not reading bugmail)]

Seems I can only reproduce the leak with ABP *and* Test Pilot enabled.  This may just be a random effect, but I don't feel like looking at this site anymore.

With Test Pilot, I see 70% heap-unclassified (250mb) after closing the tabs and minimizing memory usage, so perhaps Test Pilot is the problem.

Comment 16

[Justin Lebar (not reading bugmail)]

Okay. I now see the zombie compartment (plus 7s CC, 8m refcounted nodes) with only ABP enabled.  So test pilot is not to blame for that.

Let's make this bug about the high heap-unclassified.  I'll file a separate bug for the zombie.

The CC hang should happen only once if we get rid of the zombie.

Comment 17

[Justin Lebar (not reading bugmail)]

The unresponsive-script dialog is a general problem, see bug 718121.

The suspected ABP zombie is bug 739294.

Comment 18

[Andrew McCreight [:mccr8]]

I wonder if this is related to one of the about:newtab leaks.

Comment 19

[Andrew McCreight [:mccr8]]

Seems like orphan DOM nodes.

Comment 20

[Andrew McCreight [:mccr8]]

This node has around 1.6 million children:

0x145bed800 [rc=1653696] nsGenericElement (xhtml) body http://webpage.com/index.php?id=16778

So that's probably a factor here...

Comment 21

[Nickolay_Ponomarev]

Re comment 14: Justin, for me (no add-ons, Lion) the compartment didn't leak, but there still was high heap-unclassified after closing all tabs from the site (200-250 MB). You weren't able to reproduce that, right?

Comment 22

[Justin Lebar (not reading bugmail)]

(In reply to Nickolay_Ponomarev from comment #21)
> Re comment 14: Justin, for me (no add-ons, Lion) the compartment didn't
> leak, but there still was high heap-unclassified after closing all tabs from
> the site (200-250 MB). You weren't able to reproduce that, right?

I believe I was able to reproduce this, in approximately the size range you describe.

Comment 23

[Nicholas Nethercote [inactive]]

I just tried running DMD on the site and didn't get much useful data -- DMD slows Firefox down significantly so when opt builds are hanging DMD *struggle*.

I can believe that orphan DOM nodes are a big chunk of the heap-unclassified.  AFAICT the site's DOM operations are appallingly coded which explains why it's so slow.  Combine that with the site's general despicableness and I'm not inclined to investigate further.  Anyone object if I WONTFIX this?

Comment 24

[Justin Lebar (not reading bugmail)]

I thought orphaned DOM nodes had landed.  If not, that's almost certainly what's to blame here.

> Anyone object if I WONTFIX this?

Not I.

Comment 25

[Nicholas Nethercote [inactive]]

(In reply to Justin Lebar [:jlebar] from comment #24)
> I thought orphaned DOM nodes had landed.  If not, that's almost certainly
> what's to blame here.

It was backed out due to dromaeo regressions, unfortunately.  See bug 704623 comment 30 and onward.