712197 - Memory leak and high cpu load on crash-stats.mozilla.com when trying to drag a tab while the content is loading

Status: RESOLVED DUPLICATE of bug 702318

(Firefox :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0

The leak I'm reporting here I accidentally hit today while working on crash-stats.mozilla.com to check a couple of different reports. It has been taken a while for me to figure out under which conditions the mentioned behavior happens but meanwhile I'm able to reproduce it reliable in different versions of Firefox. So far I have tested Aurora and Firefox 9 final builds.

Before I report more details about the final behavior I will post the steps how to get Firefox into such a state.

Steps:
1. Start with a fresh profile and open http://maps.google.com
2. Open the Activity Monitor and watch the memory usage of Firefox
3. Open a crash report list like: https://crash-stats.mozilla.com/report/list?signature=js::Shape::finalize and select the Reports tab
4. Log in with your LDAP credentials
5. Open a report in another tab and log in again (necessary due to bug 711075)
6. Close tab
7. Select Google Maps and move around to let Firefox allocate a lot of memory. In my case about 400-500MB should be enough. I'm able to reach that limit in about 20 seconds
8. Switch back to the report list and open a couple of reports in new tabs
9. Wait until one the background tabs doesn't show 'connecting' anymore but starts loading the page.
10. Immediately try to drag&drop this tab and place it onto itself. If necessary repeat it a couple of times.

After step 10 you will notice a PHP fatal error at the top of the page:

Fatal error: print_r(): Cannot use output buffering in output buffering display handlers in /data/socorro/htdocs/system/core/Kohana.php on line 1600

At the same moment the cpu load will raise above 100% and the memory increases constantly until all available memory has been acquired. In my case the cpu load never goes down again, same for the memory usage until you close the tab, which is causing the problems. As longer as you wait, as harder it will become to close it.

Checking about:memory shows me that nearly all the acquired memory goes into 'heap-unclassified' and is not listed under the compartment of the crash-stats website:

Explicit Allocations
1,479.67 MB (100.0%) -- explicit
???1,093.14 MB (73.88%) -- heap-unclassified

Tomorrow I will check if that is a regression in Firefox 9, and if it is so I will find the regression range. For now it was important for me to get this bug filed with as much as possible information.

Comment 1

[Andrew McCreight [:mccr8]]

This sounds similar to bug 702318 and bug 706931.

Comment 2

[Robert Kaiser]

Yes, OI'd believe this to be a dupe of bug 702318, more or less, but there's both a Socorro and a Firefox facet to it, I believe.

Comment 3

[Robert Helmer [:rhelmer]]

(In reply to Robert Kaiser (:[e-mail]) from comment #2)
> Yes, OI'd believe this to be a dupe of bug 702318, more or less, but there's
> both a Socorro and a Firefox facet to it, I believe.

If it's a dupe of bug 702318, it's definitely a server-side bug. It's generating way too much HTML, and broken HTML due to a race condition.

The print_r in comment 0 makes me quite sure this is a dupe of bug 702318.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I ran the same tests in Firefox 8 and it is also affected. Thankfully I was not able to crash the browser, even not after letting the load process sit there for half an hour. So we should probably safe in the assumption that it cannot be used to attack users.

Beside that I'm not sure that we should completely dupe the bug against the socorro issue. Is there really nothing we can prevent Firefox from acquiring such a large amount of memory? Boris and Nicholas, what do you both think?