1308593 - Firefox repeatedly crashes OOM on 32-bit OS in safe mode during session restore

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Barry S. Finkel]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

I have a configuration with 14 windows.  With 47.0.1 FF crashes after I use it for a while.  With 48.0, FF did not stay up long enough for me to do anything.  This is on a Windows 7 Professional 32-bit system.  I have a sessionstore.js file. I assume that if someone will use this on a 48.0 Win 7 32-bit system, you will experience the crashes and be able to diagnose what is happening.

I assume that if whatever is happening with 48.0 is corrected, then my problems with 47.0.1 will be corrected.  Since 48.0 crashes almost immediately, I am
concerned now only with 48.0.

I did not try to upload one of my saved sessionstore.js files (15 Mb).


Actual results:

Here are the dump IDs for my 48.0 experience:

bp-c1d3e64d-ef89-4fd3-9037-d18462160808
bp-c1d3e64d-ef89-4fd3-9037-d18462160808
bp-78522fbc-d7b4-4764-847b-69c742160808
bp-54bdeaf3-6cae-4835-ae9c-daf382160808
bp-a0fc6b75-1793-48df-bcac-bb9202160808
bp-16dd31fd-e3ff-4bf5-8cd2-939a82160807
bp-a28b4a60-1a30-406d-ab62-3454f2160807
bp-e26a4a2a-4b4e-4dd1-ba1e-2deb92160807
bp-1701bce8-53c3-4f61-9767-1a0e92160805
bp-378341ef-3e85-4495-a5c0-1b4ca2160805

I think that I have selected only the 48.0 dumps from my large collection of 47.01.and  48.0 dumps.

Comment 1

[[e-mail]]

Hello!

I advise you to check on this Link:
https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent-and-get-help

- it shows what you should do after Firefox crashes, They can help you to Troubleshoot, Fix that crash and prevent any kind of crash of     Firefox  to any version 

-Also Do not forget to deal with your hardware device like if your RAM has a lower capacity and over used of course you have to expect a repeatedly crash of Firefox not only to Firefox 48.0 and some other versions can get that issue.

Comment 2

[Barry S. Finkel]

Here is my response.  I am an IP professional.  I spent 25+ years as an IBM mainframe systems programmer, and part of my job was to review all of the operating system dumps to determine what happened.  Then I spent 10 years as a Unix systems programmer. I do not know the details of the X86 chip, nor do I know the internals of the Windows 7 operating system.  And I do not know the internals of Firefox.  I did download the 47.0.1 source to look at a Few details, but I cannot look at a Firefox crash report/dump and determine what caused the crash.  As for the diagnostic URL you provided - I have looked at it.  I ALWAYS run in safe mode, so plugins are not involved.  I have installed all of the released MS patches for Windows 7 (except a few pertaining to Windows 10), and I run anti-virus/malware software frequently.  I have the largest amount of memory (4G) that Win 7 32-bit can use.

Here is a summary of the problem for which I opened this bug report.  I run FF with 14 windows; I have a different window for each task.  I am running FF 47.0.1, and after running for a while and accessing web pages, FF begins using 40% of the CPU and the FF process becomes (in Windows terms) "not responding".  When FF 48.0 was released, I installed it.  The results were disappointing. FF took a while to initialize (as it does with 14 windows), but FF crashed before I got a chance to do anything.

I have no idea what else I can do h to diagnose the problem.  What I suggested when I opened this bug report is this - I have a 14 Mb sessionstore.js file.  I assume that anyone who starts FF 48.0 with my sessionstore.js file - on a Windows 7 32-bit system - will experience the almost-immediate dumps.  I do not have another system on which to test this, and I assume that someone on the Mozilla FF support staff would have a Win 7 32-bit system on which to test this.  If FF 48.0 does crash, then I assume that you will have the diagnostic tools and knowledge that I do not have to determine why FF crashed..  But if my sessionstore.js file does not crash on your FF 48.0 Windows 7 32-bit system, then both of us will have more of an idea as to the next step in diagnosing the problem.

Note that at 14:21 FF was going into its "bad" state.  I did an Exit, and FF crashed during the termination process.  I restarted FF, and as I write this (16:49) FF is starting to use 40% CPU and become non-responsive.

--Barry Finkel

Comment 3

[Vlad Bacia-Mociran [:VladB]]

User Agent  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

I have tested your issue on latest FF release (49.0.1) and latest Nightly (Build ID: 20161011030212) and could not reproduce it. I have opened 14 random tabs in the browser and after that I've restarted, closed and started again the browser, multiple times but all worked fine. There was no crash. Giving the fact that you did not provide the websites used, I cannot say for sure what happens there.

While investigating the crash logs, I have found several issues that are affecting Firefox 48 and 49 but on Nightly the issues are not reproducible (Bug 1296229, Bug 1282150).

Can you please retest this using latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Comment 4

[Barry S. Finkel]

I believe your tests were not valid for my problem.  You wrote, "I have opened 14 random tabs"; were these tabs or windows?  In my case I have 14 windows, most with many tabs.  I assume that if I opened 14 windows, each with one tab, I probably would not be reaching some limit that, I believe, is part of my problem.  What I will do is this - I have your e-mail address via your reply to my problem update. i will send you a dropbox link to my 15 Mb sessionstore.js file.  I believe that this restore file will exhibit the problems with FF 48.0.  If it does crash on 48.0, then I would like to test on the most current build and on other windows versions than Win 7 Professional 32-bit.

I am limiting this trouble ticket to "FF crashes repeatedly on 49.0".  If we resolve this issue, then that resolution will probably resolve other issues I have.

Comment 5

[Vlad Bacia-Mociran [:VladB]]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

I could not reproduce this issue using latest Nightly (Build ID: 20161016030205) with the . I've created a new Firefox profile and from `about:preferences` the `Show my windows and tabs from last time` option was set. I've opened multiple windows with multiple tabs and I've restarted the browser from "Developer toolbar", on restore all windows and tabs were displayed. Using the same scenario, I've closed the browser from "Option menu", after that I've restarted it with the same profile and all windows and tabs were displayed.

I've managed to restore the windows and tabs from the `sessionstore.js` file that you've sent me. In one window there are 502 tabs and the other 13 browser windows also have multiple tabs. There was a little hang when testing with this file, but there was no crash.

Due to the fact that the issue is reproducible for the reporter I will assign a component.

Comment 6

[Barry S. Finkel]

Sorry for the delayed response.  I was away from my computer for a few days.
I have two questions.  
1) Did you run your tests on a Windows 7 32-bit system?  Maybe my problem is resource-limit-related, and the problem would not occur on a 64-bit version of Windows.  And maybe my problem is due to something in Windows 7 but will not occur on Windows 8.1.  I have a Win 8.l 64-bit system on which I can try my sessionstore.js file.  A 64-bit OS can utilize more memory than a 32-bit version; if my problem is related to a memory shortage situation, it might not occur on a 64-bit OS.

2) What is the base version for the latest nightly build?  Is it 48.0.1?  I want to look at the release notes for 48.0 and its successors to see what changes were made.  Something was changed in 48.0 (over 47.0.1) that causes FF to crash with 48.0 before I get a chance to do anything.

Note that these two questions also apply to my other bug report - 1308597.

Comment 7

[Vlad Bacia-Mociran [:VladB]]

After further investigation we managed to reproduce the issue on Windows 7 x86 using Firefox release v47.0, Firefox release v49.0.1 and latest Nightly v520a1. 

We got the following crashes: 
Firefox release v47.0: bp-6b676ffe-2071-465d-86e0-cf6de2161020
Firefox release v49.0.1: bp-ae66336c-ab77-4e6b-ab7b-41fa62161020
latest Nightly v520a1: bp-524f0623-a05d-424e-ae6e-90c9b2161020

For question 2, Firefox release builds are based on Nightly builds. Here (https://goo.gl/LBPJVA) you can find the description for the browser channels.
You can access the release notes for Firefox releases here: https://goo.gl/oVH4Sx

If you experience memory issues please consider reading this article from Mozilla Support page: https://goo.gl/c3c1Hj

(In reply to Barry S.  Finkel from comment #0)
> I assume that if whatever is happening with 48.0 is corrected, then my
> problems with 47.0.1 will be corrected.  Since 48.0 crashes almost
> immediately, I am
> concerned now only with 48.0.
Fixed bugs will be ported into the next release or build. For example, if a bug is found in Firefox v49.0.1 and it will be fixed, then the fix will be available in the next release not in the previous ones.

P.S. Please set the `Need Info` flag on the person from which you need information.

Comment 8

[Barry S. Finkel]

What is the next step?  Are you going to pursue the dumps?  I assume that the problem is due to one or more resources that are in shortage in Windows 32-bit (and not in 64-bit).  I still do not know if the problem can be reproduced on a Windows 8.1 32-bit system.  I have not looked at the Firefox code in detail, but my programming experience leads me to believe that it may be hard to determine when there is a resource shortage.  But I would prefer a warning message over a crash.

--Barry Finkel

Comment 9

[Barry S. Finkel]

Has there been any progress on this problem?  I want to close tabs that I no longer need, but after a while Firefox does not write an updated restore.js file (bug 1314403).  So, any tabs I close are not reflected in the configuration I use at startup.  Usually, when I get around to doing an Exit, Firefox either crashes during the termination process, or it (for some unknown reason) does not save a sessionstore.js file.  I could close tabs by editing the sessionstore.js or restore.js files, but I do not know of an editor that will allow me to do such an edit on a file that is a text file without any <crlf> termination characters. Thanks.

Comment 10

[Vlad Bacia-Mociran [:VladB]]

Please add the sessionstore.js file to this issue, so that other people can have access to it.

Comment 11

[Vlad Bacia-Mociran [:VladB]]

(In reply to Barry S.  Finkel from comment #9)
> Has there been any progress on this problem? 
For now the issue is marked as New and has a component assigned. This means that the issue in the developer queue and they will have a look at it when the time comes.

> I could close tabs by editing the sessionstore.js or restore.js files, 
> but I do not know of an editor that will allow me to do such an edit
You can use https://addons.mozilla.org/en-US/firefox/addon/session-manager/ , and when loading a session you can disable the unwanted tabs.

Comment 12

[Barry S. Finkel]

I would add my sessionstore.js file to this trouble ticket, but there are problems.  1) Your system will not allow a 15 Mb file to be attached, and 2) when I try to paste the Dropbox URL into the "paste the text" box, the web page will not allow me to enter anything in the box.  Here is the Dropbox URL:

https://www.dropbox.com/s/8jx1tz1gkolrfwn/sessionstore.js?dl=0

Maybe you have a way of adding the seesionstore.js file to this trouble ticket (and also to 1314403 and 1308597).

I will try the seesion-manager URL when I get a chance.  I restarted Firefox after a BSOD at 18:03, the time is now 20:28, and the restore.js file has timestamp 18:26.  So Firefox has stopped creating a new restore.js file when I make changes to a tab.  But it may, mysteriously, create a new restore.js file sometime in the middle of the night.

--Barry Finkel

Comment 13

[Barry S. Finkel]

What is the status of this bug report?  Is there anything else you need from me?  Thanks.

--Barry Finkel

Comment 14

[Wayne Mery (:wsmwk)]

There really isn't much mystery here.  Not suprising on a 32-bit OS with tons of windows/tabs, these crashes are all either outright OOM or other low-memory friends.  I speak from experience of my 32-bit days running hundreds of tabs. So it's good that you are already pursuing methods to reduce your tab count, because you shouldn't expect fixes to these OOM symptoms or loss of sessionstore any time soon - your loss of sessionstore file is likely a result of low memory - there are bugs already filed about this.

If going to 64bit OS is not possible (which I suggest is not a viable long term strategy), here is how to get to a more stable Firefox (notice I qualify with the word "more", not "totally") and perhaps also get your sesionstore working again:
1. enable 3GB https://www.google.com/search?q=3gb++switch+%22windows+7%22&ie=utf-8&oe=utf-8
2. force enable electrolysis http://lmgtfy.com/?q=force+enable+electrolysis+firefox
3. use about:sessionstore to reduce the size of sessionstore.js
4. install flashblock addon, avoid facebook and other high memory usage pages
5. make sure your AV software is using minimal resources and NOT touching firefox
6. get more than 2GB memory on your computer. memory is dirt cheap, and 2gb memory with windows 7 and modern memory hungry apps is a recipie for disappointment, if not disaster. (and you are likely on a computer where video memory is shared, steals memory from installed memory, so you probably have less than 2gb available to the OS)

I suggest this bug report, while troubling to you, is actually not terribly interesting, further tests aren't useful, and is probably a duplicate of existing "OOM" bug reports.

Comment 15

[Wayne Mery (:wsmwk)]

p.s. both bug reporters (once acquianted with crash reports) and triagers can view memory information in crash reports and reach similar conclusions

For example from bp-c1d3e64d-ef89-4fd3-9037-d18462160808
Total Virtual Memory	2,147,352,576 bytes (2 GB)
Available Virtual Memory	147,648,512 bytes (140.81 MB)
Available Page File	936,849,408 bytes (893.45 MB)
Available Physical Memory	241,180,672 bytes (230.01 MB) 

And, a 15MB sessionstore probably has 150-300 tabs.
If about:sessionstore doesn't work for you then install https://addons.mozilla.org/en-US/firefox/addon/about-sessionstore/

Comment 16

[Barry S. Finkel]

Thank you for the responses.  I have been trying to reduce the size of my sessionstore.js file, and I am down to 9.6 Mb.  But I have some problems.  After working with FF for a while, FF decides that it does not want to save a new restore.js file.  It is as if FF somehow remembers that a file was being written, so it has to wait.  And the "wait" flag is not being cleared.  I looked at the 47.0.2 source, but I did not conclude anything.  By the time I realize it, I try an Exit to do a graceful termination and save a sessionstore.js file with my current configuration.  But, by that time, FF either crashes during the termination process or terminates without saving a sessionstore.js file.  If the termination is graceful (i.e., no crash), then why is there no sessionstore.js file written?

I have noticed that before FF crashes, when I am doing nothing with FF, FF is using lots of CPU.  I have no idea what it is doing that uses lots of CPU. I have run three-minute Sysinternals Process Monitor traces, and I have looked at the output.  But I do not know enough about the internals of FF to determine what FF is doing.  And I do not know if Process Monitor is the proper tool to diagnose CPU usage; that tool seems to trace system calls.  I can understand FF running out of memory, but I do not know how that produces a spike in CPU usage.

I have also run PM traces when FF is behaving normally (not using lots of CPU) and also when FF is waiting for me to respond to the "Start in Safe Mode?" prompt.  In almost all of my three-minute traces, I see that FF is opening and reading the file

  C:\Program Files\Adobe\Acrobat Reader DC\Reader\plug_ins\Accessibility.api

I have no idea for what this file is used, nor do I know why FF is reading it.  I have told FF that when accessing a PDF file, FF should download the file and use the Adobe Acrobat Reader utility instead of using the built-in PDF reader.  And, as far as I know, I have no tabs that are downloading or reading PDF files.  I have taken this api file and renamed it; now FF only tries to open the file, not read it.  And I have seen no problems when I use Adobe Acrobat Reader by itself.  In my 22 three-minute PM traces, I have seen as few as 0, 2, and 12 opens for this file and as many as 3046, 4214, and 5002 opens.  I have three representative PM .csv files that I can give you, if you want them:

     #19 11/25 08:59   47.0.2   5 Mb    FF using 37% CPU 
     #21 12/06 09:35   47.0.2   356K    FF idle overnight
     #22 12/08 10:04   50.0.2   2.1 Mb  FF waiting at "Safe Mode" prompt

I have 4G of memory in my machine; that is the most that Windows 7 32-bit can use.  I will try the "/3G" switch to see if that affects the other applications I run on my machine.  I assume that if I use this setting, then FF will use the extra 1 Gb of memory.

I am not sure I understand electrolysis.  What I see in my about:support is:

     Multiprocess Windows 	0/14 (Disabled by add-ons)

and in about:config I have

     browser.tabs.remote.autostart     default   boolean  false  
     browser.tabs.remote.autostart.2   user set  boolean  true  

Do I change the autostart from false to true to start electrolysis?

P.S. It is now 11:25, and FF is behaving somewhat normally - using 19% of the CPU with spikest to 40%.  I have been looking at a few URLs you suggested.  I just opened a new tab, and the recovery.js file has a 10:45 timestamp.

Thanks.

Comment 17

[Wayne Mery (:wsmwk)]

> If the termination is graceful (i.e., no crash), then why is there no sessionstore.js file written?

Please check error console as described in your other bug report. 

>  After working with FF for a while, FF decides that it does not want to save a new restore.js file.  It is as if FF somehow remembers that a file was being written, so it has to wait.  And the "wait" flag is not being cleared.

No, not at all.  FWIW, I know you are trying to be helpful but it's not work speculating as to causes.  I doubt adobe is related, and I suspect traces and such are not needed.

> Do I change the autostart from false to true to start electrolysis?

yes

Be prepared that it's entirely possible you are in a situation from which you cannot possibly recover.

Comment 18

[Barry S. Finkel]

Here is a quick reply, as I do not have time now to digest everything and create a detailed reply.  I looked at my bug 1308597, and I went to the URL posted there.  I see a number of bug reports similar to mine.  You wrote in that bug report, "You should look in browser console / error console to find things relevant".  Where do I find that "browser console/error console"?

I am not trying to speculate as to the causes (except in the case where FF does not store new restore.hs files.  With the ProcessMonitor traces I was trying to determine what FF is doing when it starts using lots of CPU before it crashes.  I normally have three tabs open that update periodically, but the rest of the tabs I have open (i.e., the tabs I have accessed among my many tabs since the last restart) are static, except for an occasional ad.  If I am not at my computer accessing FF tabs/web pages, why would FF use lots of CPU?   Also you wrote "I doubt adobe is related".  But I do not know what that Adobe reader plugin accessibility.api file is and why FF would be continually opening and reading that file.  And, when FF has presented me the pop-up window for me to confirm that I really want to start in safe mode, why would FF be doing anything except waiting for my reply?

Basically, I am trying to use my 25+ years experience as an IBM mainframe systems programmer (reviewing all system dumps) to try to determine what is happening.  I knew the internals of the IBM operating systems and the programs involved.  But I do not know the internals of Windows 7 nor of Firefox.

Thanks.

Comment 19

[Barry S. Finkel]

Another related question - I am getting a pop-up window:

Firefox.exe Application Error
The exception breakpoint
An exception breakpoint has been reached.
(0x80000003) occured in the application at location 0x7351ac79.
Click on OK to terminate the program.

What is an exception breakpoint?  Is it code at a specific place in the source where the code should crash because the code has reached a place that should not happen?  Thanks.

Comment 20

[Barry S. Finkel]

Here is an update.  I have been using Chrome (which I do not like) for much of my browsing activity.  When I use Firefox, I keep track of the URL and whether the restore.js file has been updated.  This morning at 11:07, Firefox started using 40% of the CPU, and the restore.js file was current.  So. I decided to Exit gracefully.  At 11:47 Firefox had closed all of my windows, had updated the restore.js file, but was still using 50% CPU.  At 13:33, with still lots of CPU usage, I ran Process Monitor for a three-minute trace to see what Firefox was doing.  I then canceled Firefox via the Task Manager.
Here is link to the 7,052-line ProcessMonitor .csv file, which I have processed and sorted by event type:

     https://www.dropbox.com/s/ts1fnx41x5dx58x/sorted25.csv?dl=0

I really would like to know what Firefox was doing when it is using 50% of the CPU (from 11:07 until 13:57).

Thanks.

Comment 21

[Barry S. Finkel]

Here is an update.  I have been using FF less (using Chrome for regular browsing); I have been keeping a log of what I do in FF and whether the recovery.js file has been updated.  When FF begins using lots of CPU, I either Exit or cancel (via Task Manager).  Yesterday I upgraded from 51.0.1 to 52.0.  Now, I start FF, and it uses 40% of the CPU when I have done nothing in any window except unsuccessfully to try to activate the Menu Bar.  I have no idea what changes were introduced in 52.0, but I will now uninstall 52.0 and  re-install 51.0.1.

Comment 22

[Barry S. Finkel]

One further update.  Yesterday, with 52.0 using lots of CPU, I wanted to determine why FF was using lots of CPU.  The tool I use is MS Sysinternals ProcessMonitor.  I do not know of any better utility.  I ran a three-minute PM trace, and I have processed the resulting CSV file.  That 1Mb file, sorted26.csv can be found on dropbox here: https://www.dropbox.com/s/ykgx917up8ktw17/sorted26.csv?dl=0
I have looked at that file, but as I do not know the internals of Firefox nor Windows 7, I have no idea what FF was doing during that three-minute period.  There were 180 opens for the Adobe Acrobat Reader accessibility.api file; I do not understand why this file is being opened.

Comment 23

[Barry S. Finkel]

Here is an update from this past weekend:

03/10/2017 14:10  Uninstall FF 52.0, as it is unusable.
           14:20  Re-install FF 51.0.1 .
           14:28  previous.js file is written.
           15:__  Do Google searches on two Windows BSOD problems.
           16:__  FF begins using lots of CPU.
           16:58  Exit FF.
           16:58  All 14 FF windows close almost immediately.
           16:59  FF still using 50% CPU.
           17:00  I leave my computer for the night.
           17:55  recovery.bak file is written.
           17:56  recovery.js file is written.
03/11/2017 --:--  I was not at my computer all day.
03/12/2017 00:21  FF is still using 51% CPU.
                  What was it doing for 30+ hours?
           00:29  Run a 3-minute MS Sysinternals ProcessMonitor trace.
                       720 trace records produced.  100Kb
                       https://www.dropbox.com/s/eaq30jw6j63ec80/sorted27.csv?dl=0
           00:50  MS Sysinternals Process Explorer says FF is using CPU at
                       firefox.exe!GetHandleVerifier+0x3b6d.
           00:55  Cancel FF via Task Manager

Comment 24

[Kan-Ru Chen [:kanru] (UTC+9)]

Is it possible for you to install the profiler addon https://perf-html.io/ and share your report here when you find Firefox is using high CPU? After install the profiler will auto-start and you only need to click "Capture Profile" then click share".

Comment 25

[Barry S. Finkel]

I went to that add-om site, which contains instructions.  I clicked on "new version of the gecko profiler addon", snd I saw a pop-up window:

perf-html.io
Firefox prevented this site from asking you to install software on your computer.

Why the pop-up window?  Should I allow?  Thanks.

Comment 26

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Barry S.  Finkel from comment #25)
> I went to that add-om site, which contains instructions.  I clicked on "new
> version of the gecko profiler addon", snd I saw a pop-up window:
> 
> perf-html.io
> Firefox prevented this site from asking you to install software on your
> computer.
> 
> Why the pop-up window?  Should I allow?  Thanks.

It's because the add-on is not hosted on addons.mozilla.org. It's fine, you can allow it.

Comment 27

[Barry S. Finkel]

I installed the gecko profiler, but I am not sure how to use it.  I tried cntl+shift+1  and then a few minutes later  cntl+shift+2.  But nothing happened.  Once I start a trace, how long do I keep it running before I stop the trace?  Thanks.

Comment 28

[Kan-Ru Chen [:kanru] (UTC+9)]

Thanks for trying out the profiler! It's better to use the add-on icon to control it. If you are capturing without starting the profiler first, you will get error message "Error: The profiler is stopped. You need to start the profiler before you can capture a profile."

The profiler should automatically start (indicated by a blue icon) once installed. If the icon is grey, you can start it by pressing ctrl+shift+1 or using the icon menu. You can capture the trace whenever you feel the browser is abnormally using too much CPU. You can keep the profiler running as it should only uses limited resource. It does have some overhead though, so you can remove the add-on once you have captured the profile.

Comment 29

[Barry S. Finkel]

When I go to about:addons, I see that Gedcko Profiler is installed; I see boxes to Disable or Remove.
I do not see any blue icon; where should I see it?  As I am trying to type this,  FF is using 46% of the CPU.  cntl-shift-1 and cntl-shift-2 appeaar to do nothing.

Comment 30

[Vlad Bacia-Mociran [:VladB]]

Attachment: how to use the Gecko Profiler

@Barry, here is a video of how to use the Gecko Profiler. The blue circle icon from toolbar is the Gecko Profiler button. Just click it and a menu will appear. By default the Gecko profiler is automatically started at browser startup. After recording a profile click the "Capture Profile" button using the mouse/trackpad. After that a profile is generated and use the "Share..." button to get a link to that profile and paste it here in a comment. Thank you.

Comment 31

[Barry S. Finkel]

Vlad, the problem I have is with the installation of the Gecko Profiler.  I downloaded the .xpi file, and I cut-and-pasted it into the Firefox window.  I was prompted whether I wanted to install the add-on.  Then the ad-on was installed, so it told me.  And about:addons tells me that the add-on is in installed and enabled.  But I do not see the globe icon in the toolbar, so I have no idea how to start the profiler.  Thanks.

Comment 32

[Vlad Bacia-Mociran [:VladB]]

Attachment: Gecko Profiler from Customize menu

Maybe the Gecko Profiler is hidden in the Additional Tools and Features from the Customize menu. Click on the "Open Menu" button from the browser Toolbar and then click on "Customize". The Additional Tools and Features page is displayed. You need to drag&drop the Gecko Profiler button in the browser toolbar. If the Gecko Profiler is still missing please update your Firefox version and try again. Thank you.

Comment 33

[Barry S. Finkel]

The "Additional Tools and Features" icons on the page are Open File, Sidebars, Subscribe, Text Encoding, Email Link, Forget, Session Manager, and Undo Close.  

In the "Open Menu" pop-down box I have New Window, New Private Window, Save Page, Print, History, Full Screen, Find, Options, Add-ons, and Synced tabs.

In the bar near the top of each Firefox window I have icons for Download progress, Home, Bookmark this page, Show Bookmarks, Save to Pocket, Share this Page, Open Web developer tools (which I added recently), and Open Menu.

Am I looking in the correct location?

Tonight I will uninstall 51.0.1 and re-install 51.0.1; I cannot install  52.0 because it uses too much CPU.

Comment 34

[Barry S. Finkel]

Maybe I am missing something obvious.  I re-installed 51.0.1, and I still do not see a Gecko Profiler globe icon anywhere.

Comment 35

[Vlad Bacia-Mociran [:VladB]]

I investigated the Gecko issue, and there is truly a bug. The Gecko Profiler is not working in Firefox 51.0.1 x32 due to bug 1185106 (which it is fixed in Firefox v52). If you update Firefox release to latest version (v52.0.1), you can use the Gecko Profiler.

Comment 36

[Barry S. Finkel]

I am in a "catch-22" situation.  Normally, when I start Firefox with my current window/tab configuration:

     https://www.dropbox.com/s/b801601839tvwgv/restore.170321.1101.js?dl=0

(8 Mb), I let FF run for about 10 minutes until it stabilizes and stops using lots of CPU.  This is in safe mode.  When I was running 51.0.1 in regular mode to try to get Gecko Profiler operational, it took longer, but FF CPU usage eventually stabilized so that I could use FF (until something [as yet unknown] happened and FF began using lots of CPU).  I installed 52.0.1 around 10:40, and FF has been using 45% CPU since it started.  FF did start with the Gecko Profile icon, so I clicked it at 11:49:42.  About 11:53:00, I clicked it again, and FF opened a new tab:

     https://perf-html.io/from-addons/calltree/thread=0

There is a gray message block: "Waiting for symbol tables for libraries mozglue.pdb, kernel32.pdb, vcruntime140.1386..." on the same line with the green "Share..." and gray "Save as file..." buttons.  This "Waiting" has been there since, I believe noon, and it is now 13:37.  When I click either button, nothing happens.  So, I cannot save the results.  Even the down arrow to see a list of tabs for that window does not do anything.

I again ran MS Sysinternals ProcessMonitor at 13:48 for three minutes, and I have placed the resulting .csv file on Dropbox:

     https://www.dropbox.com/s/06dzs437tqfgg0k/sorted28.csv?dl=0

That file has 4,896 records from the trace of firefox.exe; I assume that ProcessMonitor is tracing Windows system calls.

Maybe you can take my restore.js file, open 52.0.1 on a Windows 7 32-bit system, and duplicate what I have experienced.
Note that I am using Chrome to post this update, as FF is currently unusable.

Thanks.

Comment 37

[Barry S. Finkel]

Here is more information.  Last night I installed a a MS monthly patch, which required a reboot.  After the reboot I started FF 52.0.1 in safe mode, and it is behaving properly (only 4% CPU usage).  I have not done much with FF since I started.  When I started 52.0.1 in regular mode yesterday, FF was unusable from the start and never recovered from its 40% CPU usage.  I may try FF today in regular mode, if I have a chance.

Comment 38

[Barry S. Finkel]

Here is mode information.

03/22 14:09  Last use of Firefox for the day.
03/23 08:01  FF (safe mode) using 40% CPU;
             restore.js has timestamp 02:09PM
03/23 08:55  Use FF to download one PDF file.
      09:00  FF using 50% CPU; restart FF with add-ons enabled.
             restore.js has timestamp 08:58AM
      09:56  Start Gecko Profiler recording.
      10:03  FF using 40% CPU.
      10:__  Stop Gecko, and a new tab opens.
             Actually three tabs opened; I must have stopped three times.
             Wait for all grey status windows to close; leave the computer
      10:41  Get back to the computer; see that Ff has crashed.
             Nothing stored in about:crashes
      11:45  Start FF in regular mode.
      13:04  FF using 41% CPU; not honoring Gecko start icon.
      13:11  FF does honor Help - Restart with add-ons disabled.
      13::__ Firefox eventually starts in safe mode.

When the Gecko Profiler has run and opened a new tab to view the
results, are those trace data stored on disk or are they, at that
point, stored in memory? __  Firefox eventually starts in safe mode

Comment 39

[Barry S. Finkel]

Here is more information.

03/24 08:30  FF using 34% CPU in safe mode; restart with add-ons.
             restore.js has timestamp 08:06AM
      08:57  FF windows appear.
      09:30  FF using 48% CPU; click on Gecko Profiler icon.
      09:40  Firefox using 29% CPU; cntl-shift-2
      09:47  nothing appears to have happened, so
             Firefox using 27% CPU; cntl-shift-2
      10:__  Two new tabs open for the profiler.
      10:30  Waiting for symbol tables for libraries xul.pdb,
                    vcruntime140.i386.pdb, ...
      10:46  FF using 38% CPU
      11:31  FF finally saves Profiler file
             Firefox 2017-03-24 09.45 profile.sps.json (4.88 MB)
      12:33  Restart FF 52.0.1 in safe mode


https://www.dropbox.com/s/4f2xpz9kjuxv8sh/Firefox%202017-03-24%2009.45%20profile.sps.json?dl=0

Does this Gecko Profiler file show anything?  I do not know how to process this file after
the fact.  

I probably will re-install Firefox 51.0.1, as 52.0.1 uses too much CPU.
Thanks.

Comment 40

[Kan-Ru Chen [:kanru] (UTC+9)]

Thanks for the profile! From the profile we know it spent a bunch of time in garbage collection. Unfortunately the profile didn't capture the js functions so we don't know what's causing that. Very likely it's due to limited memory resource combined with large amount of tabs being restored and the high cpu usage is Firefox trying to recover from the memory pressure, see comment 14, comment 15 and comment 16.

There is ongoing work to improve the session restore but your best bet is to upgrade to a 64-bit system or reduce the tabs opened.

Comment 41

[Barry S. Finkel]

I have a few questions.

1) Is there a utility that I can use to look at the trace records?  Not that I will be able to interpret what I see.

2) Are there timestamps in the records?  I want to know when the first and last trace records were captured so that I can match with my manual log.

3) Has anyone looked at the ProcessMonitor trace records that I captured?  I think that PM traces system calls, but I may be wrong.  Im the PM trace records I see lots of opens and reads of the Adobe Acrobat Reader plug-in accessibility.api file.  I do not know the use for that file, but I am confident that I have no active tabs that are downloading PDF files; I have told FF that all PDF files should be downloaded and opened with Acrobat Reader instead of being opened by the internal FF PDF reader.  If I remember correctly, I have included Dropbox links to two .csv files in this problem report.

4) What sort of garbage collection is being done?  What is the garbage being collected?

Thanks.

Comment 42

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Barry S.  Finkel from comment #41)
> I have a few questions.
> 
> 1) Is there a utility that I can use to look at the trace records?  Not that
> I will be able to interpret what I see.

You can open the trace using the web interface https://perf-html.io/

> 2) Are there timestamps in the records?  I want to know when the first and
> last trace records were captured so that I can match with my manual log.

There are timestamps relative to the program start time but no absolute time.

> 3) Has anyone looked at the ProcessMonitor trace records that I captured?  I
> think that PM traces system calls, but I may be wrong.  Im the PM trace
> records I see lots of opens and reads of the Adobe Acrobat Reader plug-in
> accessibility.api file.  I do not know the use for that file, but I am
> confident that I have no active tabs that are downloading PDF files; I have
> told FF that all PDF files should be downloaded and opened with Acrobat
> Reader instead of being opened by the internal FF PDF reader.  If I remember
> correctly, I have included Dropbox links to two .csv files in this problem
> report.

I skimmed but didn't notice anything strange.

> 4) What sort of garbage collection is being done?  What is the garbage being
> collected?

It's the garbage collector in the JavaScript engine. Executing JavaScript can create garbage (unreferenced objects), session restore create lots of them.

> Thanks.

Comment 43

[Barry S. Finkel]

One more item.  When I Exit Firefox, does garbage collection need to complete?  Yesterday at 11:07 FF was using 42% CPU, so I did an Exit.  Within a few seconds, all of my FF windows closed.  I let FF run to finish the clean termination process.  It was using about 50% of the CPU after the windows closed.  At 08:09 this morning, FF was still using 50% CPU, so I ran a three-minute ProcessMonitor trace.  That trace showed one Thread Create and two Thread Exit events.  These were the only FF events logged.  Then I cancelled FF via the Task Manager.  Thanks.

Comment 44

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Barry S.  Finkel from comment #43)
> One more item.  When I Exit Firefox, does garbage collection need to
> complete?  Yesterday at 11:07 FF was using 42% CPU, so I did an Exit. 
> Within a few seconds, all of my FF windows closed.  I let FF run to finish
> the clean termination process.  It was using about 50% of the CPU after the
> windows closed.  At 08:09 this morning, FF was still using 50% CPU, so I ran
> a three-minute ProcessMonitor trace.  That trace showed one Thread Create
> and two Thread Exit events.  These were the only FF events logged.  Then I
> cancelled FF via the Task Manager.  Thanks.

Normally Firefox will wait the tasks to complete but if it takes too long then Firefox will terminate with a "Shutdown hang" crash report.

Comment 45

[Wayne Mery (:wsmwk)]

Barry, does this and bug 1308597 still reproduce for you when using a current version?

Comment 46

[Barry S. Finkel]

Last June I migrated from Windows 7 (32-bit) to Windows 10 (64-bit). My last FF crash during Exit was 09/07/2020. On 09/13 I logged the first Exit without a crash, and I logged another at 09/14. After those two, I did not log any further FF Exits. My manual update log shows:

 08/__/2020 __:__  Mozilla Firefox 80.0   (64-bit)     (replaces 78.0.1)      when?
 09/01/2020 09:42  Mozilla Firefox 80.0.1 (64-bit)     (replaces 80.0)
 11/02/2020 14:06  Mozilla Firefox 82.0.2 (64-bit)     (replaces 80.0.1)

There may have been an update between 09/01 and 11/02 that I did not log. So, I cannot say for certain that any specific new release of FF solved the crash problem. I have not looked to see when updates between 80.0.1 and 82.0.2 were released. An update could have occurred automatically when I restarted FF, and I did not notice the update.

Comment 47

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.