Product Firefox Release Channel release Version 96.0.1 Build ID 20220113185450 (2022-01-13) Buildhub data OS Linux Mint 19.3 Tricia OS Version 0.0.0 Linux 5.4.0-96-generic #109~18.04.1-Ubuntu SMP Thu Jan 13 15:06:26 UTC 2022 x86_64

https://support.mozilla.org/en-US/kb/update-firefox-latest-version?cache=no Did you update Firefox to the latest version?

Version 96.0, first offered to Release channel users on January 11, 2022 Version 96.0.1, first offered to Release channel users on January 14, 2022

https://support.mozilla.org/en-US/questions/1359657#answer-1463359 and updated to 95.0. . . . I finally found where the plugin "Widevine Content Decryption Module provided by Google Inc." was not updating to the newest version of December 1, 2021. Ver #4.10.2391.0

cor-el; Make sure you have the latest Widevine version. You can toggle DRM off/on to see if that makes Firefox (re)load DRM components.

• Settings -> General: Play DRM
• https://support.mozilla.org/en-US/kb/enable-drm

You can possibly check the XHR requests in the Browser Console if this doesn't work.

• https://developer.mozilla.org/en-US/docs/Tools/Browser_Console

While v95 crashes and seemingly submits the crash log, I am unable to find the corresponding crash id.

bp-ae94ba15-6c3a-4479-bb81-ac4850220121 = Uptime 29 seconds bp-be228ec2-dda3-4ec0-83b0-aa25a0220121 = Uptime 35 seconds bp-f83fe60a-7439-4ed5-ae61-4e44b0220121 = Uptime 30 seconds

Signature: mozilla::dom::Promise::AppendNativeHandler

Crash Reason SIGSEGV / SEGV_MAPERR ++++++++++++++++++++++++++++++++++++++++++++++++ bp-f652f9d5-7e2b-45af-9804-1b43c0220121 = Uptime 46 seconds Signature: mozilla::loader::ImportModule

MOZ_CRASH Reason (Sanitized) : Failed to load critical module "resource://gre/modules/WebNavigation.jsm"

Crash Reason SIGSEGV / SEGV_MAPERR

This is for Sumo's Related Bugs 1724000 NEW --- Crash in [@ mozilla::loader::ImportModule]

Does not happen in new profile.

One option would be to move parts of the original profile into a new one.

FredMcD said

One option would be to move parts of the original profile into a new one.

Copying sessionstore.jsonlz4 over to the new profile, and then restoring previous session from the history menu also causes the crash.

Crash reporter is not creating any further files in ~/.mozilla/firefox/Crash Reports/submitted/ but the log file is saying the report was submitted; [Fri 21 Jan 2022 02:15:44 PM CET] Crash report submitted successfully

Copying sessionstore.jsonlz4 over to the new profile, and then restoring previous session from the history menu also causes the crash.

I suspect the file is corrupted. Delete it with Firefox closed.

Don't delete the files if you need to rescue any data from them, just move them out of the profile folder to some location where Firefox doesn't look for them. You can try to read out their contents using this tool: https://www.jeffersonscher.com/res/scrounger.html

Do you have a link to the specifications of the session file?

Details on the compression format, and the structure of the underlying json file?

How can I tell if the file is corrupted?

The scrounger loads the file without errors btw. Chromium hates me for it tho.

Tell Chromium to get over it.

This article is helpful for parsing the session file; https://www.foxtonforensics.com/blog/post/analysing-firefox-session-restore-data-mozlz4-jsonlz4

In particular, the fact that the jsonlz4 files has the header `b"mozLz40\0"` followed by block mode lz4.

It looks like the trigger of the crash could be related to loading more than 10k tabs.

Removing any combination of windows to bring the tab count below 10k seems to allow the session to load fine (in my testing profile at least).

I'm 99% sure this worked in previous versions, as I know I've been above multiple times before.

I accidentally downgraded only the language pack before.

The full session file does indeed load in v95.0.1 without crashing.

I think you need to fill out a bug report. Make sure you include all information they will need to fix the issue.

Read this first: Bug Writing Guidelines{web link}

Then go to: https://bugzilla.mozilla.org/ Be sure to include everything that the people there need to know.

The exact number of tabs does not seem to matter too much, but it is somewhere near 10k (on my system).

Do you have any advice on filing the bug-report?

I've managed to upload a few more crash reports, one with a new signature (from loading an addon after a slightly slimmed down session)

bp-7220a584-1435-4ffe-83c2-5d7f10220122 bp-f652f9d5-7e2b-45af-9804-1b43c0220121 bp-f83fe60a-7439-4ed5-ae61-4e44b0220121 bp-ae94ba15-6c3a-4479-bb81-ac4850220121 bp-be228ec2-dda3-4ec0-83b0-aa25a0220121 bp-8c80a016-04a4-4305-9313-596030220123 bp-a697d335-caf7-4f79-88fb-3b8930220123 bp-2620a1e2-ead0-4d43-a3bc-5b7f00220123 bp-6f03d541-e620-45a3-a454-f98f00220123 bp-98ae3ce5-4e63-41fc-a174-7362d0220123 bp-3dde16c2-2c9f-433a-b111-03dc40220123 bp-4cea4b27-1b4c-4a5f-a8c2-d39b90220123 bp-36d4ca2c-c871-4708-afb0-bbd1f0220123 bp-5df47f71-1e47-47fd-8c61-705e20220123 bp-c0012a2a-7bdf-486c-9b72-605860220123 bp-e903dd5d-50fd-4c2a-877b-8be5b0220123

Triggered by successfully loading a session with about 9600 tabs, and opening tabs until crash: bp-7fe355e3-51a8-4c1c-84a8-761620220123

Triggered by loading a number of tabs near what crashes, and then enabling the FoxyTab addon: bp-26bcef79-da01-4f56-929a-f57cd0220123

The tab distribution over windows in my session file: Window 1: 7865 Window 2: 148 Window 3: 205 Window 4: 162 Window 5: 842 Window 6: 51 Window 7: 54 Window 8: 41 Window 9: 83 Window 10: 173 Window 11: 11 Window 12: 20 Window 13: 168 Window 14: 69 Window 15: 26 Window 16: 18 Window 17: 26 Window 18: 53 Window 19: 83 Window 20: 77 Window 21: 309 Window 22: 3 Window 23: 3 Total tabs: 10490

While this issue seems somewhat related, and it looks like I might've tripped it once, what I'm seeing is likely something different; https://bugzilla.mozilla.org/show_bug.cgi?id=1716849

I am able to reproduce `mozilla::dom::Promise::AppendNativeHandler` at-will.

`js::UnwindEnvironment` was tripped by loading an addon while near the tab limit, and likely has the same root cause. I haven't been able to reproduce this one, but I haven't made many attempts at it.

I'm not sure of what condition produced `mozilla::loader::ImportModule` (but probably bug#1716849).

Here are the scripts I made to debug and test this issue; https://github.com/oddstr13/FirefoxSessionTools/

I opted to extract a few domains into lists of links in html files as a temporary workaround, and utilize FoxyTab to clean up some other domains.

The scrounger loads the file without errors btw. Chromium hates me for it tho.

It looks like the trigger of the crash could be related to loading more than 10k tabs.

I'm amazed the JavaScript libraries can handle it!

Removing any combination of windows to bring the tab count below 10k seems to allow the session to load fine (in my testing profile at least). I'm 99% sure this worked in previous versions, as I know I've been above multiple times before.

The full session file does indeed load in v95.0.1 without crashing.

Triggered by successfully loading a session with about 9600 tabs, and opening tabs until crash: bp-7fe355e3-51a8-4c1c-84a8-761620220123 Triggered by loading a number of tabs near what crashes, and then enabling the FoxyTab addon: bp-26bcef79-da01-4f56-929a-f57cd0220123 ... While this issue seems somewhat related, and it looks like I might've tripped it once, what I'm seeing is likely something different; https://bugzilla.mozilla.org/show_bug.cgi?id=1716849

Does Firefox run normally in the absence of extensions that query your tabs?

The sample file in the bug has 8,251 tabs, so perhaps available memory is a factor in where the problem begins -- not a hard limit.

While that bug was filed against Firefox 89, it's possible Firefox 95.0.2 added a patch that inadvertently affects enormous files.

The list of highlights in 95.0.2 is very short: "Addresses frequent crashes experienced by users with C/E/Z-Series "Bobcat" CPUs running on Windows 7, 8, and 8.1." Source: https://www.mozilla.org/firefox/95.0.2/releasenotes/ But there could be other changes. I don't know where to find a complete list, and it probably would be arduous to run a Mozregression without knowing more intimate build details.

Probably best to file a bug and get advice from the developers on narrowing it down.

Does Firefox run normally in the absence of extensions that query your tabs? The sample file in the bug has 8,251 tabs, so perhaps available memory is a factor in where the problem begins -- not a hard limit.

The presence of addon(s) seems to only affect the tab number threshold of when the crashes happen.

My main Firefox session is back up and running again now at about 8600 tabs (with my usual addons loaded), after using my scripts to move a number of domains into html files for later retrieval.

I'll see if I can't get an appropriate bugreport written up tomorrow.

Please remember to post the link to that report here.

Cross-linking issue report; https://bugzilla.mozilla.org/show_bug.cgi?id=1751720

Well done. Be sure to respond to any requests they make.