Firefox crashes daily in plugin container on Facebook
OK - I have searched and Googled.
This happens with FF 46 32 bit, 64 bit, portable, on Win 7 32 bit, 64 bit and windows 10. It happen in safe mode. It has all plugins up to date. I t has remove all but needed and non removable add ins - such as Flash, Acrobat Reader, etc. It happens on computers with plenty of RAM (16 GB). Oddly enough, it happens worse with safe mode and plugin container is run-a-way. With normal mode, it appears that plugin container is under control and Firefox itself runs amuck.
So - totally repeatable. Page down in Firefox with one or 50 tabs open - no matter. It will crash. Goes black, or stops responding. Until Firefox closes. NEVER happens with Edge for example.
I have to think it is a Firefox memory leak, but even using Firemin does not help much if at all.
What can be done? I have done my homework!
Problem signature:
Problem Event Name: APPCRASH Application Name: plugin-container.exe Application Version: 46.0.1.5966 Application Timestamp: 572818c9 Fault Module Name: mozglue.dll Fault Module Version: 46.0.1.5966 Fault Module Timestamp: 572808c3 Exception Code: 80000003 Exception Offset: 0000efdc OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
More info, of course. End of my rope on this one....
Thanks.
~Bob
Επιλεγμένη λύση
Yes noted thanks. We are not yet certain of course if this will remain the case when Firefox 50 makes it through to Release.
Ανάγνωση απάντησης σε πλαίσιο 👍 0Όλες οι απαντήσεις (20)
I believe that putting the system into Safe Mode does not go help your issue with Firefox. The problem seems to be more technical. Now, if you use Windows 10 in 1607 may be a conflict, which should go back to the previous version (1511). It may be that clear data solve part of this problem, but as I mentioned, this solution and any other technique so that I pass it only temporarily correct.
¡Hola Bob!
First of all, thanks for sticking up with us while we try to pin this one down =)
From the crash signature over at https://crash-stats.mozilla.com/signature/?signature=OOM%20%7C%20large%20%7C%20mozalloc_abort%20%7C%20mozalloc_handle_oom%20%7C%20moz_xrealloc%20%7C%20NS_CycleCollectorSuspect3 I do see there have been 180 or so other crashes like yours in the past week.
Fortunately, no crash reports for Firefox 50 nor 51 are seen there. Firefox 50 is right now Developer Edition and you could grab a copy from https://www.mozilla.org/firefox/developer/ Firefox 51 is Nightly and you could grab a copy from https://nightly.mozilla.org/ this is what I use daily and I've been so far unable to reproduce the crashes with the steps you've provided.
Could you please give either of these a run and let us know if you manage to reproduce the crash there?
¡Gracias! Alex
Alex,
Glad to know you are still following this thread and the Bug report itself.
I can't help thinking, this is not a very frequently seen signature.
There are somewhere in the order of 1/2 billion users on Firefox but using your link and looking at the summary page and the table of the number of installations that crash in the last 7 days the numbers range from 24 to 1. I suspect Bob reinstalling and testing Aurora and Nightly will just add another couple of installations and we will then see 1 installation of Fx50.0a2 & Fx51.0a1 reported for a week.
The other problem is that Bob is getting multiple Crash Signatures, if the cause of one crash signature is resolved there may well still be other crashes occur. The last Crash report with about:memory reports #c14 was a different more generic OOM report. bp-f709a9be-8459-433b-bfe3-d02302160810 that one is showing up in a few hundred installations but also not yet in Fx48.0.1 or Fx50-51
Bob
Cant help but admire your tenacity. It is of course worth trying, as is ensuring you have updated to the new Fx48.0.1 as that solved some issues and that version is also not showing on the summary table yet (but it is already showing under Fx48.0b.nn).
Did you try Ramback and what happened on the 32bit computer ? You would need to try that with all plugins disabled and all add-ons except Ramback disabled.
complete with my typos then your reply The memory shown in about:memory does not look like a problem. Did you try the RamBack addon mentioned in tha article I linked to erlier ?
* Firefox uses too much memory (RAM) - How to fix
** -> addons.mozilla.org/firefox/addon/ramback/
Does that reduce the memory usage reported by Task Manger ?Ramback has no options NOR documentation. It does nothing in 64 BIt FF. Will try 32 bit....
Samuel
Do you use Facebook ? I do not so can not try to reproduce this issue. I know Alex has tried and failed to reproduce this issue. If you have the time would you mind trying following Bob's* Steps To Reproduce. Can you crash any of your computers in this manner, or can you confirm they do not Crash please. I am sure others in this thread will have tried Bobs STR but just not explicitly reported back that they see no problem.
P.S.
Ramback
Note if you install and enable Ramback that it puts a button clear caches in the menu palette that you may drag to the Menu or a tooolbar by using the customise option.
Otherwise use the menu bar tools dropdown to get a new clear caches option (keyboard shortcut Alt+T )
You have already used about:memory note you may study various cache details from about:cache.
Yes, i use Facebook, sometimes the consumption of RAM ends up being exaggerated when I am very decendo the Timeline, but soon returns to normal when tab change. This is due to the number and size of the scripts to load. You do not notice it when you use NoScript, but leaves the defective pages because of the need to use scripts for better content display.
Had a busy morning so did not yet read the last 4 replies. I also wanted to update to 48.0.1 to see if any change. There was. Crashed earlier in 32 bit and could not open Crash Reporter after the crash, so no idea the cause.
Off to read the latest replies from you folks.
~Bob
Samuel Santos said
I believe that putting the system into Safe Mode does not go help your issue with Firefox. The problem seems to be more technical. Now, if you use Windows 10 in 1607 may be a conflict, which should go back to the previous version (1511). It may be that clear data solve part of this problem, but as I mentioned, this solution and any other technique so that I pass it only temporarily correct. https://input.mozilla.org/pt-BR/feedback
Thanks Samuel. I totally agree on Safe Mode. And on Win 10, happened with 1511. I have updated but not tried on that computer in some time. Today's crash was Win 7 64 bit all patches using FF 32 bit 48.0.1
~Bob
alex_mayorga said
¡Hola Bob! First of all, thanks for sticking up with us while we try to pin this one down =) From the crash signature over at https://crash-stats.mozilla.com/signature/?signature=OOM%20%7C%20large%20%7C%20mozalloc_abort%20%7C%20mozalloc_handle_oom%20%7C%20moz_xrealloc%20%7C%20NS_CycleCollectorSuspect3 I do see there have been 180 or so other crashes like yours in the past week. Fortunately, no crash reports for Firefox 50 nor 51 are seen there. Firefox 50 is right now Developer Edition and you could grab a copy from https://www.mozilla.org/firefox/developer/ Firefox 51 is Nightly and you could grab a copy from https://nightly.mozilla.org/ this is what I use daily and I've been so far unable to reproduce the crashes with the steps you've provided. Could you please give either of these a run and let us know if you manage to reproduce the crash there? ¡Gracias! Alex
Ola Alex,
Nice to see you again. Good news other reporting this I hope.
HAPPY to try a developer edition "again" but the problem when I tried 49 is there was NO way to disable Plugin Container. If I could disable that, I would be happy to test. But if not, it will crash in Plugin Container and that will not be helpful. And that is with NO add-ons and Flash disabled!
~Bob
John,
I already reported RAMBACK did nothing in 32 bit as well, as I recall. Drops maybe 100K. Still crashes. As well as FireMin which kept memory low in task manager FF, but does not prevent the crashing.
Samuel Santos said
Yes, i use Facebook, sometimes the consumption of RAM ends up being exaggerated when I am very decendo the Timeline, but soon returns to normal when tab change. This is due to the number and size of the scripts to load. You do not notice it when you use NoScript, but leaves the defective pages because of the need to use scripts for better content display.
I have seen this, and then going back to the open Facebook tab increases the used memory back to where it was when I switched tabs.
How much RAM is FF32 using when you deep descend into Facebook Samuel? Let it get to 3,200K and see if you crash please. For me, this is maybe the last 6 or 8 hours for friends posts.
~Bob
Firefox Container is helpful so you can run some media content such as audio and video for example. You upgraded to version 48.0.1? If so, what did you think?
In the case of a trial like Firefox Developer for example, Firefox container used is a little bit different compared with the other due to the update methods utilizandos where there may be corrections and improvements both in Firefox Container as in any Mozilla product as Firefox Beta for example.
in4m8n said
Had a busy morning so did not yet read the last 4 replies. I also wanted to update to 48.0.1 to see if any change. There was. Crashed earlier in 32 bit and could not open Crash Reporter after the crash, so no idea the cause.
There was the note on 48.0.1
If I use developer with PI Container, then Container will crash instead of FF. I do not think that is a valid test.
Each Mozilla product has a tool with differentes corrections, then it is wrong to state that such a product tool is the same as another product. In the case of Firefox Release gets updates every 6 to 8 weeks, deferent Firefox Developer that is updated more often, conseguentemente functions and tools may be similar but not identical due to the fact our products receive updates differently.
¡Hola Bob!
Plugin container crashes are expected as part of https://wiki.mozilla.org/Electrolysis
Please copy and paste the contents of the various about:crashes pages in your Firefox(es) so we can keep chasing this bugger =)
¡Gracias!
Τροποποιήθηκε στις από το χρήστη alex_mayorga
Plugin Container
If all these tests are done in Firefox's safe mode and with all plugins set to be disabled as never activate then the plugin container is not an issue.
If you enable plugins and your 40+ addons it just complicates matters.
Versions
The latest point Release Fx48.0.1 should if anything be a possible improvement as it has bug fixes in it
One of which was a js bug causing OOM crashes There should be only a few changes on a point release such as from Fx48.0 to Fx48.0.1 The differences between any full version such as Fx48 to Fx49 or Fx50 will be significant. As the end user we only notice a few if any obvious changes, but under the hood; so to speak; there are usually actually thousands of changes.
Bob
in4m8n said
Had a busy morning so did not yet read the last 4 replies. I also wanted to update to 48.0.1 to see if any change. There was. Crashed earlier in 32 bit and could not open Crash Reporter after the crash, so no idea the cause.
I hope you are talking about crashing on Facebook being faster, and that this is not an indication that you have now started getting other crashes.
There is not anything urgent about our comments in this thread, unless we get more feedback from a developer asking for information, in which case it would be good to strike whilst the iron is hot and reply as soon as practicable: No further news on that front yet.
alex_mayorga said
¡Hola Bob! Plugin container crashes are expected as part of https://wiki.mozilla.org/Electrolysis Please copy and paste the contents of the various about:crashes pages in your Firefox(es) so we can keep chasing this bugger =) ¡Gracias!
Filing such bugs may help get feedback, but I thought we had E10s off for Bob on Developer/Aurora . This is an awfull long thread to try to follow and keep track of and it is past my bedtime now.
alex_mayorga said
¡Hola Bob! Plugin container crashes are expected as part of https://wiki.mozilla.org/Electrolysis Please copy and paste the contents of the various about:crashes pages in your Firefox(es) so we can keep chasing this bugger =) ¡Gracias! OK, will try latest developer even though I think it reverts to the beginning of this thread where I thought I was crashing in Plugin Container and later realized it was crashing even without plugin container running! I shall report the crash later tonight. ~Bob
John.
YES.. That meant that Facebook crashed even earlier in memory use in 48.0.1 than previously. And DID NOT allow a crash reporter entry.
Τροποποιήθηκε στις από το χρήστη in4m8n
OK, latest Developer Edition. New profile. No add-ons, NO plugins.
Also no plugin container but TWO firefox.exe 32 applications:
See image.
Now, does NOT crash, but Facebook stops responding and goes black. So improvement?
Τροποποιήθηκε στις από το χρήστη in4m8n
Forum Note
Just a few thoughts. Alex or others may follow up some on these, or their own ideas. I can think of at least two ways forward with this
- Force a crash - we can do that in DE, but maybe not in Release, but we see Release crashes already anyhow.
- Try using built in or add-on profilers - that's awful complicated for Bob, and I for one would not understand the majority of the results generated
- Disable E10s in DE and maybe it will crash instead of freezing. Problem is we tend to get mostly generic OOM signatures. We are NOT getting about:memory reports showing unusual explicit allocation to Facebook.
- Windows Safe mode - I know Bob is against this and it is only on Firefox but having tried all these obvious steps, and knowing that this is a problem almost unique to Bobs machines (Look at Crash Stats ) it still looks like a sane and simple quick troubleshooting step.
- & what about Malware I don't think that was successfully ruled out
- about:memory NOT explicit -
That is probably the key to this issue. Of course would that issue disappear in Windows Safe Mode ? Or will one of the Developers find time to get back on this issue & be able to explain it as a graphics issue or something. - I did find someone with a possibly similar issue. I will try following that up. So far no one else is able to reproduce Bob's issue.
- File a further Crash report from a Nightly crash and include about:memory reports of at least the initial and later stages of this. (Of course it is unlikely to be a regression, we have already seen Bob's crashes in multiple Fx Releases) but it may get Developer comments
Tested for malware MANY times. And the odds of all machines being infected are VERY small.And I guarantee I could crash FF on YOUR computer, John :)
Have ANYONE contact me. We can go voice or Webex or....
I will show them how to crash if they have a Facebook account and some friends.
As to your other comments, I willlet others reply John.
Thanks.
~Bob