1820841 - Very high shmem-allocated and shmem-mapped memory usage on MacOS

Status: RESOLVED INCOMPLETE

(Core :: Graphics: WebRender, defect)

Description

[Alex M]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

No specific steps to reproduce the problem. If anything, I had a youtube video playing.

Actual results:

Memory leak was so big that it stopped firefox.

Expected results:

Memory consuption should have stayed average.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alastor Wu [:alwu]]

Is this a new issue to you? If this is a regression, could you help us use mozregression to see if you could find out the culprit?

Could you share your about:support to us? Also, it would be helpful if you can capture the profiled result while reproducing the issue. Here is the example of how to capture a profiled result.

Thanks!

Comment 3

[Alastor Wu [:alwu]]

The memory usage for other processes look very normal, but I do see an abnormal memory usage on the gfx section in the chrome process (16172). The usage is 32,654.51 MB which seems to indicate some texture leakage? On the Chrome process, it also allocated a huge amount of shmem (16,283.47 MB).

Because the leaking happened on the gfx, move this bug to the gfx component. Feel free to move it back if you determine this is a media issue. Thanks!

Comment 4

[Glenn Watson [:gw]]

Could you post your about:support ?

Comment 5

[Alex M]

(In reply to Alastor Wu [:alwu] from comment #2)

Is this a new issue to you? If this is a regression, could you help us use mozregression to see if you could find out the culprit?

Could you share your about:support to us? Also, it would be helpful if you can capture the profiled result while reproducing the issue. Here is the example of how to capture a profiled result.

Thanks!

After submitting the report, I started troubleshooting firefox. I could see the improvement. Memory was in average levels and everything seemed fine to me. After that, I enabled extensions one by one, and it stayed normal. The only two things that I can highlight is that I was working on a Figma project at the moment, and that might be the reason for high gfx usage. Also, my system had been running since the last 3 days and I never quit firefox. After restarting my computer, memory leaks stopped.

Thanks for helping.

Comment 6

[Alex M]

Attachment: Data from about:support

About my device:
I'm running firefox 110.0.1 on a Mac Air M2.

Comment 7

[Alex M]

(In reply to Alastor Wu [:alwu] from comment #2)

Is this a new issue to you? If this is a regression, could you help us use mozregression to see if you could find out the culprit?

Could you share your about:support to us? Also, it would be helpful if you can capture the profiled result while reproducing the issue. Here is the example of how to capture a profiled result.

Thanks!

Hi, I didn't answer some questions, so here they are:

This is not a new issue per se, somewhere around 4 months ago I detected the memory leak, what it wasn't as much as this time. It only happened two or three times.

I tried to reproduce the problem, but since I am not sure what caused it, I'll be leaving the browser's behaviour once I open the figma website.
Media profile | https://share.firefox.dev/3F9xKFC
Graphic profile | https://share.firefox.dev/3YzJBnk

Lastly, I tried using mozregression, but I don't really know how to use it and have no idea what to look after. Also, I can't remember any specific version that was stable.

Comment 8

[Brad Werth [:bradwerth] | Out until March 3]

I'm not sure exactly what's going on here, but looking at the "Graphic profile" from comment 7, it looks like this is triggered by a JavaScript garbage collection cycle on the Figma content process, followed by a Figma getImageData call, triggering texture readback, which causes the CanvasRenderer to resubmit all of its command buffers. The garbage collection is probably unavoidable, and the readback request is up to Figma, but we'd like to have the CanvasRenderer not drag in response to it.

It would be helpful to see if this is a regression from something we landed. Mozregression is our tool for Bug reporters like you to determine this. You don't need to have a specific date in mind, since a binary search of all Firefox releases will zero in on the issue fairly quickly. So command-line usage would look like:

mozregression --good=2022-01-01 --profile-persistence=clone-first

The clone-first param will ensure that you only need to provide your Figma credentials for the first build you test, and subsequent tests will reuse that profile. The only challenge will be if your replication case takes a lot of work or time to reproduce, because the point of the tool is to try to reproduce the issue on many different builds. So if the repro case still requires Firefox to run for 3 days, this isn't going to work.

Anyway, anything you can do to get us a reproducible testcase, or failing that, an identified regression will drastically increase the likelihood that we can solve this problem for you and for other users encountering the issue. Thank you!

Comment 9

[Andrew McCreight [:mccr8]]

As noted above, the shmem usage is very high. From the memory report, it looks like you have the Dark Space theme. So, this is probably related to bug 1828587. However, this looks like it was reported against 110, not 112, so it can't be the same thing. Maybe this is the "minimized window" case?

Comment 10

[Andrew McCreight [:mccr8]]

You could try disabling the Dark Space theme and see if that helps.

Comment 11

[Bob Hood [:bhood]]

Considering the dependent report in bug 1830753 is fixed, and that the OP is not responding to the NI after six month, I'm closing this as INCOMPLETE. Please re-open if the behavior continues to persist in current releases.