Closed Bug 657010 Opened 9 years ago Closed 8 years ago

High heap-unclassified on some sites

Categories

(Core :: General, defect, major)

defect
Not set
major

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: Virtual, Unassigned)

References

Details

(Keywords: nightly-community, Whiteboard: [sg:dos][MemShrink])

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
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
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
OS: Windows 7 → All
Version: unspecified → Trunk
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 ?
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
Thanks Thomas, my system is webkit free :-)
marking invalid due to bug in the page
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
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
Reopening, site action shouldn't hang Firefox. Protection for memory eating sites is also needed
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Whiteboard: [sg:dos]
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
Status: UNCONFIRMED → NEW
Component: General → Untriaged
Ever confirmed: true
QA Contact: general → untriaged
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.
Severity: critical → major
Component: Untriaged → General
Product: Firefox → Core
QA Contact: untriaged → general
Summary: Massive memory leak and browser hanging on certain sites → Massive memory usage, unresponsive script on jailbaitgallery.com, high heap-unclassified after closing the tab
Whiteboard: [sg:dos] → [sg:dos] [MemShrink]
Hmm.  I wonder what that heap-unclassified is made of....
Holy crap.

93% heap-unclassified.

7s CC times.  And it doesn't go away, even after I close the tabs!
8m refcounted nodes, 25k GC'ed nodes.  GC times are fast (less than 100ms).
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.
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.
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.
Summary: Massive memory usage, unresponsive script on jailbaitgallery.com, high heap-unclassified after closing the tab → High heap-unclassified on jailbaitgallery.com
The unresponsive-script dialog is a general problem, see bug 718121.

The suspected ABP zombie is bug 739294.
I wonder if this is related to one of the about:newtab leaks.
Seems like orphan DOM nodes.
Depends on: 704623
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...
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?
(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.
Whiteboard: [sg:dos] [MemShrink] → [sg:dos][MemShrink]
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?
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.
(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.
Status: NEW → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
blocking2.0: ? → ---
Resolution: WONTFIX → WORKSFORME
Summary: High heap-unclassified on jailbaitgallery.com → High heap-unclassified on some sites
You need to log in before you can comment on or make changes to this bug.