Closed Bug 1706475 Opened 3 years ago Closed 10 months ago

Restore previous session doesn't finish due to memory exhaustion (regression since 87)

Categories

(Firefox :: Session Restore, defect, P3)

Firefox 88
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: andrey_gursky, Unassigned)

References

Details

(Whiteboard: QA-not-reproducible)

Attachments

(1 file)

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

Steps to reproduce:

Provided:

  • Debian testing 64bit with Firefox from unstable (sid)
  • 4 GB RAM + 4 GB swap
  • about 6000 tabs total in 5 windows (the content only of few of them has been really loaded since last start)
  • only 3 extensions: uBlock Origin, uMatrix and Google Search Link Fix

I can reproduce it as follows:

  • quit Firefox 86
  • backup profile
  • update to Firefox 87
  • start Firefox, choose "History" -> "Restore Previous Session"
  • the whole RAM gets consumed, then almost all swap, after dozens of minutes I break the execution.
  • restore profile from backup
  • downgrade to Firefox 86
  • all works as expected

some weeks later:

  • quit Firefox 86
  • backup profile (about the same amount of tabs but not all exactly the same tabs)
  • update to Firefox 88
  • start Firefox, choose "History" -> "Restore Previous Session"
  • the whole RAM gets consumed, then almost all swap, after about 50 minutes the swap is completely in use, and I break the execution.
  • restore profile from backup
  • downgrade to Firefox 86
  • all works as expected

Actual results:

During "Restore Previous Session" Firefox 87 and 88 exhaust the whole available RAM and swap space and still cannot complete the operation.

Expected results:

During "Restore Previous Session" Firefox 86 (similarly to previous releases) consumes the whole RAM but only few MBs of swap, then more than a half of RAM is freed and Firefox becomes ready to use.

P.S. 6000 tabs sounds a lot, but from what is user visible, only the text title, the favicon and the position order get really restored (not the content of all those tabs), thus actually not so much.

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

Component: Untriaged → Session Restore

Hello I have tried to reproduce the issue with firefox 86.0 on Ubuntu 20 but i tested only with 100 tabs, then updating and restoring the session, I had no memory issues.

Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

It would really help if you can provide a memory report from about:memory, here are the steps:

1)Wait until Firefox is consuming a large amount of memory
2)In the URL bar type about:memory and press enter
3)Click "Measure and save" (optionally with "anonymize" checked to hide URLs, although this will likely make it more difficult for us to figure out which site, if any, is causing the leak)
4)Save the memory report somewhere
5)Attach the report to this bug

Another thing that would be great to have:

Please retest issue on latest Firefox nightly build, can be downloaded from here: https://nightly.mozilla.org/
Capture a performance profile using the Firefox built-in profiler. You can get more info on how to install and use the Firefox built-in profiler add-on (that helps you get the performance profile) by going to:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
http://profiler.firefox.com/
Please also note that the profiler works better on Firefox Nightly, so it's better if you are able to reproduce the issue on Nightly first.

Regards
Pablo

Flags: needinfo?(andrey_gursky)

(In reply to Pablo from comment #2)

Pablo, thanks for trying it out.

Hello I have tried to reproduce the issue with firefox 86.0 on Ubuntu 20 but i tested only with 100 tabs, then updating and restoring the session, I had no memory issues.

With 100 tabs the available for Firefox RAM/swap should be also scaled down. And I have a suspicion, that memory usage during session restore grows more than just linear with amount of tabs.

Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

Once Firefox 87 has been released and introduced this regression, I haven't reported it immediately. I'm reporting it now, because also the recently released Firefox 88 is also broken. Sure, I could also test the nightly (which I liked to avoid).

It would really help if you can provide a memory report from about:memory, here are the steps:

1)Wait until Firefox is consuming a large amount of memory
2)In the URL bar type about:memory and press enter
3)Click "Measure and save" (optionally with "anonymize" checked to hide URLs, although this will likely make it more difficult for us to figure out which site, if any, is causing the leak)
4)Save the memory report somewhere
5)Attach the report to this bug

The problem is that during session restore Firefox is not ready for use, it doesn't react on inputs.

Regarding a leak from particular site. Before closing Firefox I ensure that the active tab in all windows is an empty one. So if Firefox doesn't load the content of sites (which I guess should be the case), there couldn't be such leak?

Another thing that would be great to have:

Please retest issue on latest Firefox nightly build, can be downloaded from here: https://nightly.mozilla.org/
Capture a performance profile using the Firefox built-in profiler. You can get more info on how to install and use the Firefox built-in profiler add-on (that helps you get the performance profile) by going to:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
http://profiler.firefox.com/
Please also note that the profiler works better on Firefox Nightly, so it's better if you are able to reproduce the issue on Nightly first.

If I could enable it as argument starting Firefox in the terminal and the report could be auto saved upon ctrl+c, then it would go.

Additionally: HTML5 video auto play is disabled.

Thanks,
Andrey

Flags: needinfo?(andrey_gursky)

Most recently, substantial changes were made by DOM engineers to ensure that Session Restore is compatible with Fission. The data structures used may have a larger memory footprint than before. Looping in the relevant folks!

Flags: needinfo?(peterv)
Flags: needinfo?(kmadan)
Severity: -- → S2
Priority: -- → P3

Thanks for the report. Can you post a copy of your about:support? Mostly interested in if the fission.autostart pref is turned on. None of the core Fission Session Store changes would've been part of 87, but this still sounds pretty bad.

Flags: needinfo?(kmadan) → needinfo?(andrey_gursky)
Whiteboard: QA-not-reproducible

Firefox 88 - about:support

Flags: needinfo?(andrey_gursky)

(In reply to :kashav from comment #5)

Thanks for the report. Can you post a copy of your about:support? Mostly interested in if the fission.autostart pref is turned on. None of the core Fission Session Store changes would've been part of 87, but this still sounds pretty bad.

$ grep -i fission firefox.88.about.support.txt
Fission Windows: 0/1 Disabled by default
Fission (Site Isolation) (fission.autostart): false
fission.autostart.session: false

Thanks, so this confirms it's not Fission related. Since this doesn't reproduce in Firefox 86, are you able to run mozregression (https://mozilla.github.io/mozregression/documentation/usage.html) to see what broke this between 86 and 87?

Flags: needinfo?(andrey_gursky)
Flags: needinfo?(peterv)
See Also: → 1727519

decreasing this to S3 due to number of users that might be affected.

Severity: S2 → S3

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit BugBot documentation.

Status: UNCONFIRMED → RESOLVED
Closed: 10 months ago
Flags: needinfo?(andrey_gursky)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: