926978 - Resource leak crashes FF24.0 every day

Status: RESOLVED DUPLICATE of bug 930797

(Firefox :: Untriaged, defect)

Description

[User Dderss]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Just regular browsing, especially on HTML5 pages such as Polygon.com and TheVerge.com, which can easily grow as you browse them down.


Actual results:

1. After a while gets FF inner frame (where page's content supposed to be) shows black instead of actual content.
2. If you are immediately exit FireFox, Mozilla Crash Reporters says that FF crashed.
3. If you do not exit yourself, after short time FF crashes forcefully, also showing Crash Reporter.
4. After restart, FF does not automatically restore previous session, but shows list of tabs with checkboxes and message that there was some problem in the page.

Crash report on the case #2:
http://crash-stats.mozilla.com/report/index/c3dd4f20-c9b0-459c-bd0a-866802131015


Expected results:

1. Obviously, content of pages should not result in turning tab's inner space black;
2. If you exit FireFox, it should be able to do so without crashing on the way out;
3. If you continue browsing, FireFox should not crash;
4. FireFor launcher procedure should differentiate this type of crashing from others and not suggest that there was something wrong with TheVerge.com or Polygon.com; the crash obviously has nothing to do with code on those pages.

Comment 1

[User Dderss]

Obviously, both Windows and video drivers are fully up to date, as well as FF itself (stable release).

Comment 2

[Loic]

Your crash report doesn't help because it's empty.
Can you test with a clean profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 3

[User Dderss]

Thanks for reply; I will try it with empty profile. The crash report is empty because Crash Reporter ALWAYS says "There was a problem submitting your report" -- no matter what, I can not make it work for months and months.

For understanding whether this issue is major or not, here statistics: in just over the year, since July of 2012 to this day, I had over 250 (two hundred fifty) crashes, according to "about:crashes" page. No matter how FF's advanced during this time, the crashes never stopped. I always had updated video drivers and OS. As of recent I do not even have Flash plugin enabled, because it is a curse which crashed FF by itself without me even using the browser -- just being left alone for few hours. After switching this plugin those crashes stopped, but regular crashes did not.

Comment 4

[Loic]

Regular crashes are not normal. In many times, the culprit is a 3rd-party application (like antivirus toolbar, password manager etc) or plugins inside Firefox.

What's your AV?

Comment 5

[User Dderss]

Loic, I only have Microsoft Security Essentials AV installed, no password managers, only use built-in session FF manager.

However, it might seem that I found the culprit:

I just noticed that the crashes might be related to giant size of SessionStore JSON object, which grew from 0,5 MB to 4,5 MB in the period from July of 2012 to now -- without significant change of total tabs opened.

The file contains incredible amount of garbage that is not needed to maintain tabs and groups of tabs at all. Just chunks of data/objects from pages that I visited long time ago that were left behind as addition every time new crash has happened. This is probably how JSON became so blown up gradually.

I have "do not load" (tabs content until you active it) option always on so SessionStore.js should be skeletal despite total number of tabs kept in groups; yet it gets blown up.

Back in July of 2012 SessionStore.JS object was created anew from bookmarks, as previous one was also got incredibly blown-up to the point where it crashed FF just minutes after launch.

Having JSON for session/tabs/group tabs management is a curse because this object gets easily corrupted (my only salvation is Cobian Backup because in crashes like power failure FF can not often restore session even from *.bak file), as well as it aggregates garbage to the point where sessions are not really sustainable as in my case now. 

I am not sure how can I reproduce this in empty profile -- whole point of this bug is that it manifests after long time use of a profile. And me trying to reproduce it will not differ from me creating my current profile as new profile last year. Basically my current profile is a reproduction in a way.

What should I do? I already re-created profile last year, and SessionStore.js has blown up anyway. How to debug it?

Comment 6

[Loic]

You can reset your profile to test, instead of creating a new one from scratch:
https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems

Remember some add-ons/extensions are able to crash Firefox in various cases.

Comment 7

[User Dderss]

But I did even clearer nuke option last year, and yet SessionStore JSON continued to blow up.

I know I can again start anew as I did last year, but it does not get us anywhere in debugging how FF core engine leaves so many garbage SessionStore and never cleans it up.

How can we debug this issue?

Comment 8

[User Dderss]

Attachment: memory-report.json.gz

This is memory map for my session of FireFox right of the start. I have "Load on click" option used, so memory map should be skeletal. Yet my 4.5 MB SessionStore.js explodes to nearly half gigabyte just on load when FireFox only shown one page at best. (SessionStore.JS for about the same about of tabs I have was 0.5 MB last year, when I imported tabs into new profile, but continued to collect garbage and grew to 4.5 MB now.)

Comment 9

[User Dderss]

SessionStore.js is full of data of links and pages I visited long time ago. For example, this chunk of data was part of Facebook "Like" button that FF rendered over month ago when I read Verge article from September, 5th:

__________________________________________________________________

{"url":"https://www.facebook.com/plugins/like.php?api_key=268249759880745&channel_url=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D27%23cb%3Df18d7d9ccae3986%26domain%3Dwww.theverge.com%26origin%3Dhttp%253A%252F%252Fwww.theverge.com%252Ff1b74b57b4be9e8%26relation%3Dparent.parent&colorscheme=light&extended_social_context=false&href=http%3A%2F%2Fwww.facebook.com%2FThisIsTheVerge&layout=button_count&locale=en_US&node_type=link&sdk=joey&send=false&show_faces=false&width=90","title":"Facebook","ID":12495,"docshellID":6088,"referrer":"http://www.theverge.com/2013/9/5/4698808/most-common-encryption-protocols-are-useless-against-nsa-surveillance","docIdentifier":12614,"scroll":"0,0"}

__________________________________________________________________

Obviously page with Verge article does not exist in any opened tab or in "recently closed" tabs; it was opened and closed over month ago.

SessionStore.JS accumulates information on all of pages it rendered from links I visited in last 14 months since I last nuked my previous profile (because it has blown to over 6 MB at that point).

Obviously SessionStore.JS should not contain this garbage and FF core engine should be able to clean it up by itself, but it can not do it, even in 24th version.

Comment 10

[Loic]

I don't think this file is the root cause of your crashes, it's just a file to store your session (tabs) you want to restore. 6 MB is pretty low.

But I see you have many add-ons. You should try with a profile that has been reset.

Comment 11

[User Dderss]

For starters, I killed my SessionStore.js again and imported all the same tabs from bookmarks.

When FireFox is not running, the size of SessionStore.js file is 800 KB instead of 4.5 MB as it was before. There is no garbage in it (for now) and, when I run FireFox, there are no crashes of this type any more (so obviously with the clean profile I will not get that crash either).

Since it is not the first time that I had to kill my session that got corrupted to the point where FF began to randomly crash itself after some use, my questions are:

1) why SessionStore.js object blows up in state when FF is not running, collecting objects from renders of pages that were opened and *closed* in tabs for months or ever over a year ago? (https://bugzilla.mozilla.org/show_bug.cgi?id=926978#c9)

2) why even with "Load on click" option turned on, SessionStore.js still keeps in itself anything besides list of tabs and groups -- while FF is *not* running?

The main question is obviously #1, but if there was way to make FF *not* keep any pages as objects in SessionStore.js when FF is not running, as questioned in #2, then it would not get corrupted and FF would not crash.

Who could know answers to those two questions? How do I file a request for a fix for that?

Comment 12

[Wayne Mery (:wsmwk)]

Seesion restore is quite different now in new releases.
Can you still reproduce this issue?
If not, please close by setting status to RESOLVED and resolution to WORKSFORME

Comment 13

[User Dderss]

In newer stable releases SessionStore does not get so blown up, and the main culprit in case of this bug was not SessionStore blowing up wither, it was -- and is -- 32-bit FireFox always running out of continuous virtual memory. This issue is unsolvable untile Mozilla will roll out release-class version 64-bit FireFox.

Status of this bug should be "CONFIRMED" and "WONT FIX" as apparently Mozilla does not want to update browser's code so it would care for itself. This is why the crutches like https://addons.mozilla.org/addon/prevent-out-of-virtual-memo are needed, those are the only way to avoid daily crashed for active/heavy users.

If Mozilla would change its mind and implement build-in tracking for continuous virtual memory size (and hence blacking out and OoM crashes would be avoided), then it would be fair to change the status to "RESOLVED" and "WORKSFORME".

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to User Dderss from comment #13)
> In newer stable releases SessionStore does not get so blown up, and the main
> culprit in case of this bug was not SessionStore blowing up wither, it was
> -- and is -- 32-bit FireFox always running out of continuous virtual memory.
> This issue is unsolvable untile Mozilla will roll out release-class version
> 64-bit FireFox.

This is an assumption on your part, and not necessarily true until the cause if your high memory usage is determined.

> Status of this bug should be "CONFIRMED" and "WONT FIX" as apparently
> Mozilla does not want to update browser's code so it would care for itself.

Bugs tend to not get confirmed until we narrow down what might be causing the issue.  For example you earlier cited Polygon.com - which is certainly not an average type website.  I would focus on that 

> If Mozilla would change its mind and implement build-in tracking for
> continuous virtual memory size (and hence blacking out and OoM crashes would
> be avoided),

I don't understand what this means. Please point us to a specification or programming model or methodology which describes what you are talking about.


For the record, to touch on some of the older comments of this bug report...

(In reply to User Dderss from comment #9)
> SessionStore.js is full of data of links and pages I visited long time ago.
> For example, this chunk of data was part of Facebook "Like" button that FF
> rendered over month ago when I read Verge article from September, 5th:
>... 
> Obviously page with Verge article does not exist in any opened tab or in
> "recently closed" tabs; it was opened and closed over month ago.
> 
> SessionStore.JS accumulates information on all of pages it rendered from
> links I visited in last 14 months since I last nuked my previous profile
> (because it has blown to over 6 MB at that point).
> 
> Obviously SessionStore.JS should not contain this garbage and FF core engine
> should be able to clean it up by itself, but it can not do it, even in 24th
> version.

this is no longer true - in current Firefox very old session data gets trimmed.
you can see the contents using the about:sessionstore add-on


(In reply to Loic from comment #10)
> I don't think this file is the root cause of your crashes, it's just a file
> to store your session (tabs) you want to restore. 6 MB is pretty low.
> 
> But I see you have many add-ons. You should try with a profile that has been
> reset.

Indeed - what addons do you have installed?
And, how many tabs do you typically have open?

Comment 15

[User Dderss]

Verge and Polygon were simply the sites that I was visiting most often at the time of when this bug was filed, and at that point the issue was not researched yet. But since then it was already explored in many bugs (bug #930797, bug #733262, and many more: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=mozalloc_abort&list_id=12288527).

First victim is often times video/graphics renderer, so the image starts to black out. If the requested chunk is too big from very beginning, then FF just crashes immediately without any gradual visual deterioration.

Maximum continuous virtual memory in 32-bit browsers quickly approaches zero and FF can not allocate the requested continuous piece for whatever purpose and has OoM crash.

So there is nothing to investigate here already.

Comment 16

[Wayne Mery (:wsmwk)]

It sounds then, like this is really just a variation of bug 930797