On Exit, Firefox crashes after writing sessionstore.jsonlz4
The more important problem is this - When I Exit Firefox, Firefox almost always crashes AFTER it has written the sessionstore.jsonlz4 recovery file. I am not sure why Firefox is crashing. Here are my latest crash reports; I just submitted a few that about:crashes told me that I had (for some unknown reason) not yet submitted:
bp-443cad89-7ff9-4b46-a08a-1dc7f0190520 5/20/2019 9:53 AM bp-206d878c-2234-439f-a4e4-680d50190520 5/20/2019 9:15 AM bp-470cb28b-9389-4e85-bf84-643240190520 5/20/2019 9:53 AM bp-5be78b3c-edf3-4aec-bf15-8920c0190517 5/17/2019 4:24 PM bp-d0f1ce9d-ac2a-40c8-bb87-b58fb0190517 5/17/2019 4:24 PM bp-cf37500d-4501-4e39-8588-2e0760190516 5/16/2019 10:40 AM bp-cd595694-e613-4d05-8e0f-713960190515 5/15/2019 8:15 AM bp-b4e32309-4c8b-4d4e-954b-c6d1b0190513 5/13/2019 9:21 AM
When I look at a crash dump summary, I do not see the crash time. I do see the install time and the install age, but I do not have time to "add" the two to produce the crash time so that I can equate a given crash with my manual log to determine which of these crashed occurred after an Exit. I suggest that the crash dump summary be enhanced to give this information.l And the summary I save (via cut-and-paste) before I submit each crash report does not give the crash dump ID.
For the record, I am running 66.0.5 32-bit on Windows 7, always in safe mode.
Modified by cor-el
Additional System Details
- Shockwave Flash 32.0 r0
- User Agent: Mozilla/5.0 (Windows NT 6.1; rv:66.0) Gecko/20100101 Firefox/66.0
hi bsfinkel, thank you for reporting with some crash ids - please try if the following step is making a difference: press ctrl+shift+del in firefox to bring up the dialog to clear recent history, select the time range "everything", untick all boxes except "offline website data" and let firefox clear that. does firefox shut down cleanly after that?
I have cleared the offline website data. I will Exit Firefox sometime in the future. I was looking at my recent (April and May) crash dumps, and I am having a hard time coordinating each crash dump with the crashes that I have logged in my manual log. I have the crash time from the detail before I submit the crash report (I have a Python script to convert the timestamp), but the "Install time" + "Install Age" does not match the crash time I have logged.
And, when I looked at about:crashes this morning, I see LOTS of crash dumps that have not been submitted, and I have no idea why. I have manually logged all Firefox crashes, and for only a few have I not submitted the reports.
When I see in a crash report "Crash Reason: EXCEPTION_BREAKPOINT", what does that mean?
Here is an update. I do not want to add more problems to this thread, but I am getting confused. My last report was 05/20/2019 around 09:20 (the last dump I reviewed was sent at 09:15). My manual log shows these FF crashes since that time::
05/24 09:03 (during an Exit) 05/24 14:10 (during an Exit)
But when I look at "about:crashes" I see 13 crash dumps that have been sent since 05/20 09:15. I see these Install times:
1 2019-02-13 15:34:12 65.0.1 5 2019-03-01 15:59:21 65.0.2 1 2019-03-24 02:08:05 66.0.1 1 2019-04-10 19:10:03 66.0.3 3 2019-05-08 13:49:50 66.0.5 1 2019-05-21 13:15:38 ?? 1 2019-05-24 14:54:14 67.0
The 05-21 13:15:18 is when I cleared recent history. What I do not understand is why I manually submitted TWO crash dumps, but the FF log shows I have submitted 13, all of which have various install times (and thus various older crash times and versions of Firefox).
One thing I can report (per the previous trouble ticket) is that with the two crashes today, the crash report was very quick. So the history info I cleared did resolve that problem. The two crash IDs from today:
Both are EXCEPTION_BREAKPOINT crashes, and sesssionstore.jsonlz4 WAS written successfully.
One thing I can report (per the previous trouble ticket) is that with the two crashes today, the crash report was very quick. So the history info I cleared did resolve that problem. The two crash IDs from today: bp-2f37eee3-6633-419d-8975-0c2e80190524 bp-bed0b539-ad22-4789-ba10-1b4330190524 Both are EXCEPTION_BREAKPOINT crashes, and sesssionstore.jsonlz4 WAS written successfully.
The first is Firefox 67.0 and has the signature @ OOM | small and seems to indicate that Firefox requested 168 bytes of contiguous memory from Windows and was declined. That seems too small to be true, so there's probably more to the story, or it might help to restart Windows.
The second is Firefox 66.0.5 and has the signature @ shutdownhang | js::GCParallelTask::join. If my "date math" is correct, this occurred several hours earlier, so apparently there was an update in between.
Note that installTime items in the crash report folder have nothing to do with crashes, but are added when Firefox is updated (you posted the Firefox version that was about) See also the "Show update history" button on the "Help -> Troubleshooting Information" (about:support) page.
- Firefox 67.0 Crash Report [@ OOM | small ]
- Firefox 66.0.5 Crash Report [@ shutdownhang | js::GCParallelTask::join ]
The first report from Firefox 67 is about OOM (out-of-memory) where not enough contiguous free memory is available. Are you using the recommended size for the Windows pagefile?
See the Firefox Task Manager (about:performance) page. https://support.mozilla.org/en-US/kb/task-manager-tabs-or-extensions-are-slowing-firefox
Total Virtual Memory : 2,147,352,576 bytes (2.15 GB) Available Virtual Memory : 228,270,080 bytes (228.27 MB) Available Page File : 8,933,023,744 bytes (8.93 GB) Available Physical Memory : 459,722,752 bytes (459.72 MB) System Memory Use Percentage : 86 OOM Allocation Size : 168 bytes
Today (05/24) at 09:15 I rebooted after uninstalling Dropbox (for another problem) . I Exited FF at 09:00, and FF crashed at 09:03. Before the reboot I saw that FF had an update to install.
After the reboot, FF auto-updated from 66.0.5 .to 67.0. Then, since I had not opened many additional applications and I had not seen an EventID 55 NTFS error (which causes an unnecessary 12-minute "chkdsk c:" at the next reboot), I decided to install new MS Patch KB4505050. I did an Exit in FF at 14:08 prior to the patch install and required reboot, and FF crashed at 14:10. So, I have rebooted twice today.
"Note that installTime items in the crash report folder have nothing to do with crashes...". I know that. I keep a manual log of FF crashes, and I need to take the install time and add to it the uptime (I need to figure out how to do that automatically) to get the crash time. I keep a copy of the crash details I manually submit, and I am trying to determine which crash report corresponds with which crash detail I have manually submitted after a FF crash. As I wrote in an earlier post, I suggest that the crash time be included in the crash report I see via "about:crashes" so that I do not have to do the addition manually.
The crash time is in the crash report.
2f37eee3-6633-419d-8975-0c2e80190524 => CrashTime : Fri, 24 May 2019 19:10:09 GMT
When I look at this specific crash via "about:crashes" I see in the "Details" tab these line headings in grey:
Signature UUID 2f37eee3-6633-419d-8975-0c2e80190524 Date Processed Uptime Last Crash Install Age Install Time Product Release Channel Version Build ID OS OS Version Build Architecture CPU Info CPU Count Adapter Vendor ID Adapter Device ID Startup Crash False MOZ_CRASH Reason (Sanitized) MOZ_CRASH() Crash Reason Crash Address Total Virtual Memory Available Virtual Memory Available Page File Available Physical Memory System Memory Use Percentage OOM Allocation Size EMCheckCompatibility App Notes Processor Notes
I do not see "Crash Time". I am running 67.0; are you running a beta version where "Crash time" has been added?
I do see in the "Metadata" tab: CrashTime 1558725009 and I can use my Python script to convert that to GMT -
D:\computer>rem Convert a Firefox CrashTime integer to a timestamp.
D:\computer>rem 23Sep13 0847PM Barry Finkel
D:\computer>rem 05Dec13 0841AM Changed to use \temp (either C: or D:)
D:\computer>echo 1558725009 1>\temp\ffcrshtm.in
D:\computer>rem type \temp\ffcrshtm.in
I have had more occurrences of this problem. At each occurrence, I tell the crash reporter window to submit the report and restart Firefox. But when I went to "about:crashes" a few minutes ago, I saw that the last three occurrences had NOT been submitted. Each one had the "Date Submitted" timestamp that agreed with the date and time that I clicked "Restart Firefox". Here are the IDs of these three crashes:
bp-755453dd-0ce8-41b9-8040-bdc940190617 bp-cf087d93-a626-4c87-9ca5-8760e0190613 bp-2e3fa550-fe12-4115-8d08-40dc70190606
I still want to know why Firefox is crashing after writing the sessionstore.js configuration file. Thanks.
Here is another reply, I have had two further occurrences:
A "shutdown hang" crash is recorded when shutdown hits the maximum time limit. I can't tell what Firefox was doing before the "shutdown hang" occurred, so I don't know whether it is related to sessionstore.jsonlz4, recovery.jsonlz4, or some other file(s).
Is this max time limit a value that I can change? I would prefer Firefox to take a bit longer during termination rather than to crash and then me having to log and process the crash dump. Thanks.
I can't test this myself, but you could experiment:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.
(2) In the search box above the list, type or paste crash_ and pause while the list is filtered
(3) By default, the toolkit.asyncshutdown.crash_timeout preference has a value of 60000 milliseconds (60 seconds). You could double-click that and change it to 90000 (90 seconds) to see whether it actually is the relevant value (i.e., you get the dialog 90 seconds after shutdown instead of 60 seconds after shutdown).
I made the change, and I will wait for the next time I have to restart Firefox. Thanks.