![பயர்பாக்ஸ் logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
Crash on start, just after saved tabs are restored, presumably before or when the tab contents start loading
Crash also happens when passed the argument `-safe-mode`. Does not happen in new profile. Crash happens both in v96.0.1 and after downgrading to v95.0.1. Console output mentions "Exiting due to channel error." I have not been able to find a way of increasing output verbosity.
$ ls -1 ~/.mozilla/firefox/Crash\ Reports/submitted
bp-ae94ba15-6c3a-4479-bb81-ac4850220121.txt
bp-be228ec2-dda3-4ec0-83b0-aa25a0220121.txt
bp-f652f9d5-7e2b-45af-9804-1b43c0220121.txt
bp-f83fe60a-7439-4ed5-ae61-4e44b0220121.txt
$ firefox
- !!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
ExceptionHandler::GenerateDump cloned child 20567 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error.
All Replies (20)
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.
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]
Oddstr13 said
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
Oddstr13 said
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.
Oddstr13 said
The scrounger loads the file without errors btw. Chromium hates me for it tho.
Oddstr13 said
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.
Oddstr13 said
The full session file does indeed load in v95.0.1 without crashing.
Oddstr13 said
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.
jscher2000 said
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.