Bug 1093593 - firefox 29 using ridiculous amounts of memory on rawhide
Summary: firefox 29 using ridiculous amounts of memory on rawhide
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-02 07:28 UTC by Peter Robinson
Modified: 2014-09-23 12:09 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-09-23 12:09:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
about:memory firefox using 6Gb RAM (1.62 MB, application/x-gzip)
2014-05-02 07:28 UTC, Peter Robinson
no flags Details
after 24hrs of run back to using over 5Gb RAM (1.18 MB, application/x-gzip)
2014-05-03 09:22 UTC, Peter Robinson
no flags Details
post minimise memory back down to arounf 3Gb (1.14 MB, application/x-gzip)
2014-05-03 09:23 UTC, Peter Robinson
no flags Details
within 5 mins of running the minimise memory it's back up to over 6gb (1.22 MB, application/x-gzip)
2014-05-03 09:27 UTC, Peter Robinson
no flags Details
latest about:memory with new profile (286.96 KB, application/gzip)
2014-06-17 16:18 UTC, Peter Robinson
no flags Details

Description Peter Robinson 2014-05-02 07:28:22 UTC
Created attachment 891729 [details]
about:memory firefox using 6Gb RAM

My firefox instance usually uses around 2-2.5 gb of RAM. Since upgrading to firefox 29 in rawhide (firefox-29.0-5.fc21.x86_64) it's using up to 6gb of RAM 

about:memory reports that a basic mailing list text page is using 100Mb of RAM (http://www.spinics.net/lists/arm-kernel/msg296378.html)

I'm attaching the about:memory log, let me know what else you need

Comment 1 Martin Stransky 2014-05-02 08:41:55 UTC
Well, it looks like:

4,481.06 MB (100.0%) -- js-main-runtime
├──3,557.50 MB (79.39%) -- gc-heap
│  ├──3,461.63 MB (77.25%) ── unused-arenas

Can you try the "Minimize memory usage" button? How log do you run FF? Can you please test a binary from mozilla.com?

Comment 2 Peter Robinson 2014-05-02 08:49:42 UTC
(In reply to Martin Stransky from comment #1)
> Well, it looks like:
> 
> 4,481.06 MB (100.0%) -- js-main-runtime
> ├──3,557.50 MB (79.39%) -- gc-heap
> │  ├──3,461.63 MB (77.25%) ── unused-arenas
> 
> Can you try the "Minimize memory usage" button? How log do you run FF? Can
> you please test a binary from mozilla.com?

I had tried the minimise not long earlier and the uptime of the machine is only a day but I'd restarted it at least twice. With FF-28 I could run it for well over a week without issues and the link above would take up a few Mb of memory, not nearly into the 3 digits. 

I'll do my best to try a mozilla.com binary but what sort of things explicitly do you want me to test.

Comment 3 Martin Stransky 2014-05-02 09:49:56 UTC
(In reply to Peter Robinson from comment #2)
> I'll do my best to try a mozilla.com binary but what sort of things
> explicitly do you want me to test.

I just like to know if there's any difference between Fedora and Mozilla binary...

Comment 4 Peter Robinson 2014-05-03 09:22:42 UTC
Created attachment 892102 [details]
after 24hrs of run back to using over 5Gb RAM

Comment 5 Peter Robinson 2014-05-03 09:23:50 UTC
Created attachment 892103 [details]
post minimise memory back down to arounf 3Gb

Comment 6 Peter Robinson 2014-05-03 09:27:23 UTC
Created attachment 892104 [details]
within 5 mins of running the minimise memory it's back up to over 6gb

Comment 7 Peter Robinson 2014-05-03 09:29:39 UTC
So after 24 hours of running it's back up to over 6gb. Running "minimise memory usage" took it back down to around 3Gb (which is still higher than the usual 2Gb or so v28 would sit at) but within 10 mins it was back up to over 6Gb of RAM usage (and huge cpu usage).

Will now try the upstream binaries over the next 24 hrs

Comment 8 Peter Robinson 2014-05-03 09:37:04 UTC
Initial run with upstream firefox 29 running from a terminal with all my tabs open and loaded and the memory is at around 2.1Gb which is what Fedora F-28 would usually sit at. Will watch it over the next day

Comment 9 Peter Robinson 2014-05-03 18:11:00 UTC
So with upstream running over 10 hours it grew to 6Gb+ too, minimise the memory and it drops to around 2.6Gb but within minutes it's back up to 6Gb+ just like on the Fedora build.

Comment 10 Martin Stransky 2014-05-05 07:35:23 UTC
Thanks for the testing. I tend to say it's something with rawhide, we don't have any similar report from Fedora 20/19...It looks like the memory is not returned to system after free() or so.

Comment 11 Peter Robinson 2014-05-05 08:18:45 UTC
(In reply to Martin Stransky from comment #10)
> Thanks for the testing. I tend to say it's something with rawhide, we don't
> have any similar report from Fedora 20/19...It looks like the memory is not
> returned to system after free() or so.

so... what's the next steps?

Comment 12 Martin Stransky 2014-05-07 12:37:47 UTC
I don't have any steps now. AFAIK Rawhide packages are build with debug on which causes performance/memory issues.

Comment 13 Peter Robinson 2014-05-07 12:42:35 UTC
(In reply to Martin Stransky from comment #12)
> I don't have any steps now. AFAIK Rawhide packages are build with debug on
> which causes performance/memory issues.

User space packages are NOT built with debug on. Some rawhide kernels are built with debug on which can slow rawhide down. I am not running a debug kernel and the entire OS isn't slow and the entire OS isn't consuming gigs more of RAM than usual. This problem _IS_ with firefox and nothing else.

Comment 14 Peter Robinson 2014-05-07 16:06:44 UTC
And having now downgraded to Firefox 28 (firefox-28.0-3.fc21.x86_64) and been running it for 3 hours with the same tab set open it's only using currently using 1.3Gb of RAM.

Comment 15 Peter Robinson 2014-05-08 08:41:00 UTC
running now for around 15 hours on FF28 and only using 1.5gb of RAM. Definitely an issue with FF-29 on rawhide

Comment 16 Peter Robinson 2014-06-06 10:41:08 UTC
Getting closer to the bottom of this. It looks like it's gstreamer related. When I tried FF 30 (firefox-30.0-1.fc21.x86_64) I was getting out right crashes. It seems abrt doesn't get backtraces or even detect FF crashes though. Running from a command line I got more details about gstreamer. 

I added No Flash (https://addons.mozilla.org/en-US/firefox/addon/no-flash/) yesterday (with FF-28) as I don't have Flash installed and it updates some supported sites to do the HTML-5. With FF-30 I believe as soon as it tried to load a supported site with the HTML5/gstreamer side it killed firefox straight up.

Comment 17 Peter Robinson 2014-06-06 14:25:58 UTC
It seems it doesn't like the fluendo plugin pack in the slightest. If I remove that I'm still getting regular crashes today but no where near as many

$ firefox

(process:12410): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
console.error: lightbeam: 
  log
  blocking 0 sites
Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object file: No such file or directory
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0

ERROR: Caught a segmentation fault while loading plugin file:
/usr/lib64/gstreamer-0.10/libgstfluvadec.so

Please either:
- remove it and restart.
- run with --gst-disable-segtrap --gst-disable-registry-fork and debug.
pure virtual method called
terminate called without an active exception
$

Comment 18 Martin Stransky 2014-06-10 14:18:50 UTC
Please test firefox-30.0-2 - it's build with gstreamer-1.0.

Comment 19 Peter Robinson 2014-06-10 15:23:23 UTC
(In reply to Martin Stransky from comment #18)
> Please test firefox-30.0-2 - it's build with gstreamer-1.0.

it has the same issues

Comment 20 Peter Robinson 2014-06-11 13:20:03 UTC
(In reply to Martin Stransky from comment #18)
> Please test firefox-30.0-2 - it's build with gstreamer-1.0.

In fact it's likely worse, I've rebuilt FF-30 without gst support so as to be able to rule it out.

Can you provide some details or links for actually debugging this. All the links I've found to date seem to not work on the newer versions of FF

Comment 21 Martin Stransky 2014-06-11 13:30:44 UTC
Some how-to is here: https://fedoraproject.org/wiki/How_to_debug_Firefox_problems
But I think the best is to test in safe mode with a fresh profile.

Comment 22 Peter Robinson 2014-06-11 14:41:04 UTC
> But I think the best is to test in safe mode with a fresh profile.

Do you want me to do a completely clean OS install while I'm at it?

Comment 23 Martin Stransky 2014-06-12 10:30:56 UTC
I mean a Firefox profile. by $firefox -ProfileManager

Comment 24 Peter Robinson 2014-06-17 16:17:27 UTC
So I took a copy (just URLs into a text document of the 100 odd tabs) I had open over 4 windows. Killed firefox, moved my profile out of the way. Started firefox and it created a new blank profile.

To this I added the following extensions:
* LastPass 3.1.1
* HTTPS Everywhere 3.5.1
* Adblock Plus 2.6.3
* Lightbeam 1.0.10.1

All plugins are set to "ask to activate" and I don't have Flash installed. I don't have any services installed.

I currently have a mere 34 tabs open and it's using 4.1Gb of RAM according to about:memory (will attach)

There's nothing particularly exciting about the tabs I have open:
* a few RHBZ
* a few koji.fedoraproject.org and arm.koji.fedoraproject.org
* A few fedoraproject.org/wiki
* A few access.redhat.com docs package
* A few of random mostly test based mail list archive pages
* A few fpaste.org
* Trello
* Google mail/calendar/keep/plus
* Roundcube mail
* Feedly

I mean there's this page (http://www.spinics.net/lists/netdev/msg286323.html) which is pure text with some hyperlinks taking up 73mb of RAM (saved page is 31K)

Comment 25 Peter Robinson 2014-06-17 16:18:10 UTC
Created attachment 909680 [details]
latest about:memory with new profile

Comment 26 Peter Robinson 2014-09-23 12:09:01 UTC
with v32 it's improved although I can't see what's changed


Note You need to log in before you can comment on or make changes to this bug.