Open Bug 1747679 Opened 3 years ago Updated 2 years ago

high mem usage

Categories

(Core :: Graphics: ImageLib, defect, P3)

Firefox 95
defect

Tracking

()

Performance Impact low

People

(Reporter: jronpaul, Unassigned)

Details

(Keywords: perf:resource-use, Whiteboard: [memshrink])

Attachments

(5 files, 1 obsolete file)

1.13 MB, application/gzip
Details
37.91 KB, text/plain
Details
868.55 KB, application/gzip
Details
33.67 KB, image/png
Details
37.91 KB, application/octet-stream
jronpaul
: review+
Details
Attached file memory-report.json.gz

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Name Firefox
Version 95.0.1
Build ID 20211215221728
Distribution ID min
open firefox.. i have a about 100 tabs open
and it uses all my 8G of memory and starts to use swap

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

pid 1380 has some large-ish numbers for WR/Imagelib.

@jronpaul : are you able to tell which that pid 1380 corresponds to which webpage?
Also, please attach your about:support

Flags: needinfo?(jronpaul)

damn... its on my wife's computer and she restarted firefox. i can wait until it starts using memory again and send another report.

ive attached the about:support

Flags: needinfo?(jronpaul)
Attached file about:support

here is a memory report from the latest firefox..
the memory usage is steadily increasing.

Attached file memory-report.json.gz (obsolete) —

here is a memory report from the latest firefox..
the memory usage is steadily increasing.

Attached file memory-report.json2.gz

ow the laptop is maxing out memory.

         total        used        free      shared  buff/cache   available

Mem: 7.6Gi 6.3Gi 221Mi 656Mi 1.0Gi 330Mi
Swap: 2.0Gi 1.9Gi 114Mi

attached a new memory report...

Attachment #9257000 - Attachment is obsolete: true
Attached image mem.png

here is what happens when i close firefox and open it again..
you can see how high the mem usage was..
and now it will steadily increase past 100% utilization again

Component: Widget: Gtk → General
Priority: -- → P1
Component: General → Performance

When you attached about:support, was it before or after the issue was seen? I'd be curious as to its contents after the memory is growing. While there aren't an extraordinary number of images mapped into the parent process (it is often high), I am suspicious of just how many of those images are missing a creator ref. That would imply we only want to keep them alive until the next frame is processed, but surely we shouldn't see that many.

I don't think we handle early returns well when we create ScheduleSharedSurfaceRelease:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#482

If there are missing fonts or something, e.g.:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#626

Combined with animated image updates, we might leak the images too. However there should be entries in the critical log if that is the case, and that should show up in about:support.

Flags: needinfo?(jronpaul)

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)

When you attached about:support, was it before or after the issue was seen? I'd be curious as to its contents after the memory is growing. While there aren't an extraordinary number of images mapped into the parent process (it is often high), I am suspicious of just how many of those images are missing a creator ref. That would imply we only want to keep them alive until the next frame is processed, but surely we shouldn't see that many.

I don't think we handle early returns well when we create ScheduleSharedSurfaceRelease:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#482

If there are missing fonts or something, e.g.:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#626

Combined with animated image updates, we might leak the images too. However there should be entries in the critical log if that is the case, and that should show up in about:support.

ok.
attached a new about:support.

Flags: needinfo?(jronpaul)
Attached file ff.about

latest about:support

Attachment #9257374 - Flags: review+

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)

When you attached about:support, was it before or after the issue was seen? I'd be curious as to its contents after the memory is growing. While there aren't an extraordinary number of images mapped into the parent process (it is often high), I am suspicious of just how many of those images are missing a creator ref. That would imply we only want to keep them alive until the next frame is processed, but surely we shouldn't see that many.

I don't think we handle early returns well when we create ScheduleSharedSurfaceRelease:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#482

If there are missing fonts or something, e.g.:
https://searchfox.org/mozilla-central/rev/fac07284a9a996ddf968ea53adaf25c2a8b7c520/gfx/layers/wr/WebRenderBridgeParent.cpp#626

Combined with animated image updates, we might leak the images too. However there should be entries in the critical log if that is the case, and that should show up in about:support.

ohh.. sorry, i didnt answer your question.. the 1st about:support that was attached was when it was in the middle of high mem usage. i believe.

Interesting. It could be a different problem then..... perhaps I can augment the memory reports in a better way.

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #13)

Interesting. It could be a different problem then..... perhaps I can augment the memory reports in a better way.

sorry, im not sure what you mean exactly.. but let me know if there is anything else I can supply.

Hey Andrew, just pinging you to answer above questions and keep the bug moving :-) Thanks!

Flags: needinfo?(aosmond)

any updates?
thanks

Attachment #9257000 - Attachment mime type: application/json → application/gzip

There does not appear to be anything in the critical log in about:support. I'm not sure if I have much to go on by here. I did land bug 1749526 which should handle complete transactions, and avoid memory leaks for animated images in those events. Does the latest nightly help at all?

Flags: needinfo?(aosmond)

I also don't see much evidence in the about:memory dumps that the problem is related to images / surfaces.

Summing up the "resident" sizes of all processes in each report, I do get something around 8GB, which matches the reporter's description.

attachment 9257123 [details]: 9271.84 MB
552.23 + 727.46 + 681.12 + 514.61 + 491.87 + 420.78 + 369.68 + 276.82 + 264.38 + 252.11 + 235.52 + 226.93 + 208.17 + 191.80 + 183.93 + 156.24 + 141.29 + 139.87 + 133.48 + 130.92 + 130.56 + 129.56 + 122.18 + 120.83 + 119.60 + 118.91 + 118.16 + 114.83 + 111.57 + 108.25 + 107.77 + 105.59 + 104.39 + 102.76 + 101.23 + 98.68 + 97.89 + 94.80 + 94.54 + 92.24 + 89.70 + 84.21 + 83.22 + 82.75 + 80.52 + 78.94 + 71.78 + 71.77 + 69.86 + 33.68 + 31.86

attachment 9256878 [details]: 7943.07 MB
692.18 + 360.95 + 347.82 + 329.25 + 284.12 + 235.82 + 220.04 + 213.34 + 209.39 + 203.71 + 193.20 + 179.21 + 170.69 + 151.66 + 144.94 + 138.65 + 137.81 + 125.44 + 121.74 + 109.00 + 107.16 + 100.69 + 100.21 + 93.92 + 90.79 + 89.54 + 88.01 + 86.86 + 85.72 + 84.37 + 82.62 + 79.86 + 78.14 + 75.91 + 75.77 + 73.95 + 72.61 + 71.68 + 70.95 + 70.73 + 70.43 + 70.20 + 66.81 + 65.78 + 65.40 + 64.43 + 62.46 + 62.13 + 59.56 + 59.31 + 57.59 + 55.46 + 53.93 + 52.30 + 52.20 + 51.37 + 51.31 + 50.36 + 49.18 + 48.84 + 48.17 + 46.79 + 45.53 + 41.32 + 40.27 + 37.21 + 36.61 + 35.66 + 34.86 + 34.59 + 34.55 + 32.89 + 30.86 + 14.32 + 11.94

attachment 9257000 [details]: 8271.72 MB
820.03 + 596.90 + 555.11 + 355.20 + 329.19 + 311.38 + 302.23 + 295.17 + 292.30 + 265.19 + 263.52 + 245.45 + 215.48 + 196.41 + 188.64 + 165.61 + 162.02 + 150.37 + 147.68 + 144.16 + 143.84 + 136.06 + 134.82 + 130.29 + 129.40 + 126.58 + 123.29 + 120.86 + 114.09 + 112.72 + 112.52 + 108.63 + 102.97 + 96.93 + 95.32 + 92.84 + 89.11 + 72.61 + 72.44 + 72.13 + 42.12 + 40.11

But the memory seems to be mostly used by web pages / JS memory. It looks like lots of tabs are opened or loaded and never closed. Restarting helps because tabs are loaded lazily.
Or maybe something leaks the tab contents? Or maybe there's a leak in an add-on?
Unloading background tabs when memory becomes tight would help here.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P1 → P3
Whiteboard: [memshrink]

definitely have a lot of tabs open and most just sit there..
she is leaving them up to remind her to look at them..
i have also told her that they need to be saved and closed..
that said, i thought it seemed like using all the memory was a bit much..
i loaded her .mozilla file onto a server I have with 62G of memory and it used 18G when i launched ff
and loaded all the tabs.

The Performance Priority Calculator has determined this bug's performance priority to be P3. If you'd like to request re-triage, you can reset the Performance flag to "?" or needinfo the triage sheriff.

[x] Causes severe resource usage

Performance Impact: --- → low
Component: Performance → Graphics: ImageLib
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: