Bug 245953 - www/firefox randomly lockups for about 30+ seconds
Summary: www/firefox randomly lockups for about 30+ seconds
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-gecko (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2020-04-26 23:26 UTC by aryeh.friedman
Modified: 2023-04-23 14:45 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (gecko)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description aryeh.friedman 2020-04-26 23:26:22 UTC 
I have not been able to reliably find a way to trigger this issue but the latest update to www/firefox will randomly become non-responsive to user events for 30 or more seconds.   I have yet to determine any pattern to this behavior the only clue I can give is that removing the custom mapping for my up arrow key (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244290) all apps locked up during these lockups.
Comment 1 aryeh.friedman 2020-04-26 23:29:43 UTC 
(In reply to aryeh.friedman from comment #0)
oops before removing the custom mapping it locked apps up
Comment 2 Jan Beich freebsd_committer freebsd_triage 2020-04-27 03:28:50 UTC 
Needs more affected users to track down the cause and/or upstream input.

- Can you reproduce after restarting with dom.ipc.processCount=1 or MOZ_FORCE_DISABLE_E10S=1 ?
- Does bug 245422 patch help? I plan to land it today, so it should be in packages around 2020-04-29.
Comment 3 aryeh.friedman 2020-04-27 03:40:33 UTC 
(In reply to Jan Beich from comment #2)

I have zero experience with FF under the hood so I have no idea how to either those settings and/or where to get a (non-publicly available?) patch.
Comment 4 aryeh.friedman 2020-04-27 03:52:27 UTC 
(In reply to aryeh.friedman from comment #3)
Never mind figured out how to do both... Will try both and if no problem after a day or so will put processCount back at 8
Comment 5 Jan Beich freebsd_committer freebsd_triage 2020-04-27 04:32:39 UTC 
When testing make sure dom.ipc.processCount matches "Remote Processes" in about:support. A few releases ago Firefox introduced Performance menu in preferences, so one has to unset "Use recommended performance settings" (aka browser.preferences.defaultPerformanceSettings.enabled) to unlock dom.ipc.processCount.
Comment 6 aryeh.friedman 2020-04-27 09:43:30 UTC 
(In reply to Jan Beich from comment #5)
Setting processCount to 1 works fine in both pre-pathched and patched but setting it to the default of 8 in both versions leads to the same random freezeups
Comment 7 aryeh.friedman 2020-04-28 02:33:19 UTC 
(In reply to aryeh.friedman from comment #6)
I was wrong it still freezes on processCount=1 (post patch) but less frequently.  I am switching back to 8 because it is way to slow to load complex pages on 1 (any recommendations for an intermediate setting?)
Comment 8 Graham Perrin freebsd_committer freebsd_triage 2021-12-28 07:00:17 UTC 
(In reply to aryeh.friedman from comment #7)

Do you have an account at FreeBSD Forums?
Comment 9 Graham Perrin freebsd_committer freebsd_triage 2023-04-23 14:45:10 UTC 
Reproducible with 112.0.1_1,2 or greater on FreeBSD 13.2-RELEASE?