Open Bug 1786247 Opened 1 month ago Updated 17 days ago

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

Categories

(Core :: Widget: Gtk, defect)

Firefox 86
defect

Tracking

()

Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 --- affected
firefox104 --- wontfix
firefox105 --- wontfix
firefox106 --- affected

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: memory-leak, regression)

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)
You need to log in before you can comment on or make changes to this bug.