Closed Bug 1786247 Opened 6 months ago Closed 3 months ago

Theme with animated gif background has a steady memory leak when window is completely covered by another window

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 86
defect

Tracking

()

RESOLVED INCOMPLETE
107 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 --- wontfix
firefox104 --- wontfix
firefox105 --- wontfix
firefox106 --- wontfix
firefox107 --- fixed

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: memory-leak, regression)

Attachments

(4 files)

STR:

  1. Start with MOZ_ENABLE_WAYLAND=1 on Ubuntu 22.04 (GNOME 42.2).
  2. Install a theme with a large animated gif background like Dark Space.
  3. Open two windows and completely cover one with the other window.

Total system memory usage climbs steadily when window is completely covered and only released when it becomes visible. It is not attributed to any Firefox process in about:processes or the system Task Manager but can be measured in about:memory gfx section of main process.

It does not happen with widget.wayland.vsync.enabled = false or if the window is minimized, on a different workspace or covered by a different application.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=69e6477b290b4f6d2beffffd3520e07d51685182&tochange=d9b0105477475ee9d411fdd67d37b1774aedb3da

Regressed by Bug 1629140.

5,667,318,356 B (100.0%) -- gfx
└──5,667,318,356 B (100.0%) -- webrender
   ├──2,951,682,644 B (52.08%) -- textures
   │  ├──2,719,208,644 B (47.98%) ── render-texture-hosts
   │  ├────100,663,296 B (01.78%) ── render-targets
   │  ├─────87,293,952 B (01.54%) -- texture-cache
   │  │     ├──87,293,952 B (01.54%) ── atlas
   │  │     └───────────0 B (00.00%) ── standalone
   │  ├─────22,201,744 B (00.39%) ── swap-chains
   │  ├─────16,777,216 B (00.30%) ── depth-targets
   │  ├──────2,785,280 B (00.05%) ── gpu-cache
   │  ├──────2,752,512 B (00.05%) ── vertex-data
   │  ├──────────────0 B (00.00%) ── picture-tiles
   │  ├──────────────0 B (00.00%) ── texture-upload-pbos
   │  └──────────────0 B (00.00%) ── upload-staging-textures
   └──2,715,635,712 B (47.92%) -- images/mapped_from_owner
      ├──2,710,929,408 B (47.83%) -- pid=3271
      │  ├──2,703,052,800 B (47.70%) ── image(640x360, compositor_ref:2, creator_ref:1)/decoded-other [2933]
      │  ├──────6,451,200 B (00.11%) ── image(640x360, compositor_ref:1, creator_ref:1)/decoded-other [7]
      │  ├────────921,600 B (00.02%) ── image(640x360, compositor_ref:26, creator_ref:1)/decoded-other

Uh, interesting. This is a specialty of the Wayland vsync source approach and can probably be fixed by implementing bug 1695227

See Also: → 1695227

For the record: do I understand correctly that the memory is not leaked, but just "queued" until the window is visible again?

Why would a stalled VsyncSource lead to accumulated unreleased memory for an obscured window? Stuff generated on a different timer that is only released on a VsyncSource tick? :/

(In reply to Kenny Levinsen :kennylevinsen from comment #3)

Why would a stalled VsyncSource lead to accumulated unreleased memory for an obscured window? Stuff generated on a different timer that is only released on a VsyncSource tick? :/

Yeah, something like that...I think stalled VsyncSource is simply not expected in other parts of the stack - the renderer should get suspended instead. The Wayland one it AFAIK the only one where this can happen for longer periods. But this shouldn't be hard to fix with some timeout or so.

Robert, do you intend to work on this bug or should we find an owner?

Flags: needinfo?(robert.mader)

(In reply to Pascal Chevrel:pascalc from comment #5)

Robert, do you intend to work on this bug or should we find an owner?

I'm afraid I won't find time ATM, so finding an owner would be good indeed.

Flags: needinfo?(robert.mader)

Martin do you think that this should block our meta bug for Wayland general availability? (bug 1752398)

Flags: needinfo?(stransky)

Sure, why not.

Flags: needinfo?(stransky)

Tested on latest nightly but I'm unable to reproduce. Also Dark Space doesn't work for me (at least I don't see anything animated) so I'm using sakura theme for testing (https://addons.mozilla.org/en-US/firefox/addon/animated-sakura-by-candelora/).

Kestrel, can you please check again with latest nightly?
Thanks.

Flags: needinfo?(ke5trel)

I can't reproduce it with ANIMATED Sakura either, perhaps because of the image format (png, 2.2MB, ~1 second). I can still reproduce it on latest Nightly 107.0a1 (2022-10-10) with Dark space (gif, 2.7MB, ~8 seconds) and The Generator (GIF) (gif, 5.9MB, ~7 seconds).

Flags: needinfo?(ke5trel)

Thanks, will check the Generator theme.

It's because we fail to recycle decoded images but we keep to create a new ones. I wonder if that's related to two vsync/refresh drivers running together while one doesn't fire VSync events as it's hidden.

Assignee: nobody → stransky
Priority: -- → P3

To fix this one we need to fire some vsync events even when the window is hidden. AFAIK refresh driver fires two ticks per second for hidden windows. We may also fire OcclusionStateChanged() if window is hidden for long time.

Attachment #9298070 - Attachment description: Bug 1786247 [Wayland] Use StaticPrefs::layout_idle_period_required_quiescent_frames() to set idle frame rate r?rmader → Bug 1786247 [Wayland] Use layout.throttled_frame_rate to set idle frame rate r?rmader
Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/94ddd239c0d6
[Wayland] Print nsWindow as part of Vsync logs r=rmader
https://hg.mozilla.org/integration/autoland/rev/87e8a37d1e93
[Wayland] Add Vsync idle callback r=rmader
https://hg.mozilla.org/integration/autoland/rev/f063a768cbf1
[Wayland] Implement Vsync idle callback and fire reduced vsync events if nsWindow is hidden r=rmader
https://hg.mozilla.org/integration/autoland/rev/6b355532cd2d
[Wayland] Use layout.throttled_frame_rate to set idle frame rate r=rmader
Flags: qe-verify+

I have managed to reproduce this issue on Release v106.0.1 launched with wayland Window Protocol on gnome desktop environment.
I've done so by installing the Dark Space theme mentioned originally and opening 2 windows where one visually covers the other. By watching the Memory and Swap section of the System Monitor I can observe that the memory rises slowly until the hidden window is brought into focus, then the memory drops back to the base level.

The fix confirmation was attempted on Beta v107.0b4 and Nightly v108.0a1, but it appears to still reproduce in the same manner.

Martin, is the method I'm using a valid method?

Flags: needinfo?(stransky)

(In reply to Bodea Daniel [:danibodea] from comment #20)

I have managed to reproduce this issue on Release v106.0.1 launched with wayland Window Protocol on gnome desktop environment.
I've done so by installing the Dark Space theme mentioned originally and opening 2 windows where one visually covers the other. By watching the Memory and Swap section of the System Monitor I can observe that the memory rises slowly until the hidden window is brought into focus, then the memory drops back to the base level.

The fix confirmation was attempted on Beta v107.0b4 and Nightly v108.0a1, but it appears to still reproduce in the same manner.

Martin, is the method I'm using a valid method?

Please file a new bug for it and attach about:memory reports. Also please attach about:support page.
Thanks.

Flags: needinfo?(stransky) → needinfo?(daniel.bodea)

I can still reproduce this leak in latest Nightly 108.0a1 (2022-10-25) on Ubuntu 22.04, the memory report is the same as before:

4,126.39 MB (100.0%) -- gfx
└──4,126.39 MB (100.0%) -- webrender
   ├──2,219.32 MB (53.78%) -- textures
   │  ├──1,912.55 MB (46.35%) ── render-texture-hosts
   │  ├────128.00 MB (03.10%) ── render-targets
   │  ├────118.50 MB (02.87%) -- texture-cache
   │  │    ├──118.50 MB (02.87%) ── atlas
   │  │    └────0.00 MB (00.00%) ── standalone
   │  └─────60.27 MB (01.46%) ++ (7 tiny)
   └──1,907.06 MB (46.22%) -- images/mapped_from_owner
      ├──1,902.16 MB (46.10%) -- pid=19542
      │  ├──1,892.29 MB (45.86%) ── image(640x360, compositor_ref:3, creator_ref:1)/decoded-other [2153]
      │  └──────9.87 MB (00.24%) ++ (24 tiny)
      └──────4.91 MB (00.12%) ++ (2 tiny)

It initially seemed to be fixed until Bug 1795574 was corrected.

Status: RESOLVED → REOPENED
Depends on: 1795574
Flags: needinfo?(daniel.bodea)
Resolution: FIXED → ---

Oh, that could be because https://searchfox.org/mozilla-central/source/widget/gtk/WaylandVsyncSource.cpp#281-296 - after bug 1795574 we now unconditionally set the occlusion state to visible again. Emilio, can you have another look?

Flags: needinfo?(emilio)

(In reply to Robert Mader [:rmader] from comment #23)

Oh, that could be because https://searchfox.org/mozilla-central/source/widget/gtk/WaylandVsyncSource.cpp#281-296 - after bug 1795574 we now unconditionally set the occlusion state to visible again. Emilio, can you have another look?

That change should be correct - if we get frame callback from wl_surface it means the surface is visible. This is not related to Vsync - we just use one source (frame callback) for two independent purposes.

The core fix here is that we fire VSync event even when we don't get frame callback. That allows gecko to release unused resources (cached decoded images in this case) so we don't need to allocate new ones but uses image recycling. I wonder if we hit a different bug or the Vsync does not free the cached images.

Yeah I don't think that is to blame... The occlusion code seems to work locally, fwiw...

Flags: needinfo?(emilio)

The regression range includes some relevant Webrender changes and the bug does not occur with the Basic compositor. I will file a separate bug in the Webrender component.

Assignee: stransky → nobody
Status: REOPENED → RESOLVED
Closed: 4 months ago3 months ago
Regressed by: 1676909
No longer regressed by: 1629140
Resolution: --- → INCOMPLETE
Summary: [wayland][vsync] Theme with animated gif background has a steady memory leak when window is completely covered by another window → Theme with animated gif background has a steady memory leak when window is completely covered by another window
See Also: → 1797978
No longer regressed by: 1676909
You need to log in before you can comment on or make changes to this bug.