1422614 - Apparent memory leak

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[Matthew.T.Hoare]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171130105051

Steps to reproduce:

Ran Firefox for several hours.

(Arch Linux, fully updated, Zen-patched kernel)


Actual results:

Memory usage (as reported by the ps_mem utility[1]) increases over time.

Initially ~550MiB, after 8 hours it is now at ~1.3GiB.

I ran it under valgrind, this is the only error message reported:

"[Parent 3872, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /build/firefox/src/mozilla-unified/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709"

[1] https://github.com/pixelb/ps_mem


Expected results:

Memory usage should stay roughly static over time (unless lots more tabs are opened) and I don't think FF should be using almost 1.5GiB at any stage.

Comment 1

[Cristina Badescu [:cbadescu], Experiments QA]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171128222554

Hello Matthew,

I have tested this issue using Arch Linux 4.12, on Firefox release 57.0.1, latest Nightly build 59.0a1 (2017-12-06) and could not reproduce it. I have accessed different websites and kept running both Firefox release and Firefox Nightly for a couple of hours (approximately 4 hours). The memory usage wasn't high and the registered values were between 170 and 270 MiB.

Can you please retest this using latest Firefox release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause.

Comment 2

[Matthew.T.Hoare]

Thanks!

I have started FF 57.0.1 (from the Arch repositories) in safe mode and will test that tonight.

A few things though:

Why are you using such an old kernel in your Arch Linux system?

I have the [testing] repositories enabled and `uname -a` gives:

"Linux Xanadu 4.14.4-1-zen #1 ZEN SMP PREEMPT Tue Dec 5 14:05:50 UTC 2017 x86_64 GNU/Linux"

Perhaps this problem only occurs with a recent kernel?

Get the latest kernel from Arch with:

`pacman -Syu`

Secondly, how are you measuring memory usage?

I linked to my tool in my report and it shows this immediately after starting FF:

 Private  +   Shared  =  RAM used	Program
187.9 MiB +  44.8 MiB = 232.7 MiB	firefox
194.0 MiB +  57.8 MiB = 251.8 MiB	Web Content (2)

So I would say that was ~480MiB, if we wanted to compare like-with-like.

Comment 3

[Matthew.T.Hoare]

After five hours or so (in safe mode) we have:

282.6 MiB +  36.1 MiB = 318.7 MiB	firefox
556.3 MiB +  71.5 MiB = 627.8 MiB	Web Content (4)

I've closed several tabs since starting FF and there are only 7 left open.

Comment 4

[Cristina Badescu [:cbadescu], Experiments QA]

Hello Matthew,

> Why are you using such an old kernel in your Arch Linux system?

That's the testing machine I have access to and after running "pacman -Syu", it tells me that core is up to date.

> Secondly, how are you measuring memory usage?

This time I've installed ps_mem utility and I've used that to measure the memory usage. 
I have retested this issue on the Arch provided Firefox and here are the results:
At initial launch:
218.8 MiB +  35.3 MiB = 254.1 MiB	firefox
769.0 MiB +  86.7 MiB = 855.8 MiB	Web Content (4)

After 4 hours:
240.8 MiB +  30.8 MiB = 271.6 MiB	firefox
692.8 MiB +  64.4 MiB = 757.2 MiB	Web Content (4)

Given the fact that this seems to be related to your setup, could you please install the Gecko Profiler add-on (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler) and post a link to the performance profile?

Comment 5

[Matthew.T.Hoare]

If you have FF v57.0.1 (from the Arch repositories) and kernel 4.12 co-installed then that system has been subjected to a partial upgrade and this is unsupported by the Arch Linux developers.[1]

Did pacman download any database files at all? I think there may be a problem with /etc/pacman.d/mirrorlist, perhaps check for /etc/pacman.d/mirrorlist.pacnew and merge the differences — mirrors do get dropped occasionally.

Anyway, I installed the Gecko Profiler, here is the snapshot at the start of the session:

https://perfht.ml/2ADrpzF

A few hours in and ps_mem has some rather alarming news:

513.5 MiB +  40.8 MiB = 554.3 MiB	firefox
  1.4 GiB +  85.5 MiB =   1.5 GiB	Web Content (4)

With this snapshot from the profiler:

https://perfht.ml/2AFk82c

I hope these help and I would also just like to say that apart from the memory issue the browser is performing extremely well indeed and seems to be blazingly fast so good work there :)

[1] https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported

Comment 6

[Cristina Badescu [:cbadescu], Experiments QA]

Hello Matthew,

Thank you for the provided info and for your feedback. If you don't mind, could you please test this issue on the Official Mozilla binary or on the latest Nightly build (https://nightly.mozilla.org/)? I'm not sure, but this issue might be caused by something that's in the Arch repack. Testing on official Firefox versions will help us exclude this theory.

Comment 7

[Matthew.T.Hoare]

OK, I will try both this weekend.

Just FYI, here are the Arch patches for FF:

https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/firefox

The prepare() section of the PKGBUILD shows how (and why) they are applied ;)

Comment 8

[Matthew.T.Hoare]

I ran the Nightly (v59) build this afternoon.

It all started well, see the ps_mem output in Head_on_a_Stick's screenshot: https://forums.bunsenlabs.org/viewtopic.php?pid=65193#p65193

But after eight hours or so we have:

Xanadu: ~ $ sudo ps_mem | grep 'firefox\|Content'
564.7 MiB +  46.7 MiB = 611.4 MiB	firefox
  1.1 GiB +  86.1 MiB =   1.2 GiB	Web Content (4)
Xanadu: ~ $

Here is a link to the Gecko Profiler output (it wouldn't finish "Waiting for symbol tables for library libxul.so" so I had to kill it and save the file instead, hope that's OK):

https://drive.google.com/open?id=1uTucvue9UnrYx3ttDIdQ8ddi-2hg4lgw

Thanks!

Comment 9

[Cristina Badescu [:cbadescu], Experiments QA]

Hello Matthew,

Indeed, such a profile would help us figure it out, but the provided one doesn't have the symbols. Can you please retry and wait for the symbols to be properly loaded? 

Also, there is one more thing you can do if you don't mind: please attach the memory report when you encounter the issue. You can do this by navigating to "about:memory" page, click on the "Measure and save..." button and attach the file.
Thanks!

Comment 10

[Matthew.T.Hoare]

397.5 MiB +  47.5 MiB = 445.0 MiB	firefox
  1.1 GiB +  89.0 MiB =   1.1 GiB	Web Content (4)

Also, double-clicking on the empty space next to the tabs will reliably crash FF, I now use this as a "close" button :P

Profiler:

https://perfht.ml/2jzcHFJ

about:memory:

https://drive.google.com/open?id=1s7p5TSNLbd46YOF0WX6FSm4E7eq4Myw6

Good luck!

Comment 11

[Cristina Badescu [:cbadescu], Experiments QA]

Hello Matthew,

Thanks for the provided info! Mike, can you please take a look at the provided Cleopatra profile and the "about:memory" report in comment 10 and see if it helps to find out what caused the issue?

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Thanks Matthew.T.Hoare / Cristina.

The profile shows a nicely behaving Firefox, not behaving slowly or dropping frames, so I think we can stop collecting those for this particular problem.

The memory report... I'm less sure about (and less skilled at analyzing at this point).

Matthew.T.Hoare: If you go to about:config and set dom.ipc.processCount to 1, and restart, do you notice that the lone content process continues to grow over time? Or does it reach some kind of limit?

Comment 13

[Eric Rahm [:erahm]]

The memory report was taken while the profiler was running so it's not going to give us actionable information.  Can you test with the original set of pages with the profiler disabled and take a memory report at the start and then a memory report when you feel we're using too much memory and attach those here? That will help us do a diff and see what memory is in use.

Comment 14

[Cristina Badescu [:cbadescu], Experiments QA]

Due to the fact that I cannot reproduce this issue and the fact that the reporter didn't provide the requested info from comment 12 and comment 13 until now, I'm going to close this issue as Resolved-Incomplete.

If anyone can still reproduce it on the latest versions, please feel free to reopen the issue and provide more information.