Closed Bug 1137251 Opened 9 years ago Closed 9 years ago

Massive memory leak with Firefox 36+ (maybe related to WebGL)

Categories

(Core :: Graphics: CanvasWebGL, defect)

36 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla39
Tracking Status
firefox36 + verified
firefox37 + verified
firefox38 + verified
firefox39 + verified
relnote-firefox --- 36+

People

(Reporter: bernhard.robert.pichler, Assigned: jgilbert)

References

Details

(Keywords: regression, Whiteboard: gfx-noted)

Attachments

(6 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

Steps to reproduce:

Open a website which is using my 2D rendering engine - like this example:

http://www.stagexl.org/show/spine/raptor/example.html




Actual results:

Starting with Firefox 36 it seems there is a massive memory leak going on. This didn't happen with a previous version of Firefox and does not happen with a different browser. Maybe i'm doing something wrong but still it worked in the past on Firefox without any problems. The memory goes to 1GB and reached 2GB a few seconds later. From there on the memory usage goes up without end - everything get's very slow of course.


Expected results:

The memory usage should be constant like in previous versions of Firefox or in other browsers.
Regression range:
good=2014-10-10
bad=2014-10-11
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=50b689feab5f&tochange=f74ad36bb97b

I suspect bug 1066280.
Status: UNCONFIRMED → NEW
Component: Untriaged → Canvas: WebGL
Ever confirmed: true
Flags: needinfo?(jgilbert)
Keywords: regression
Product: Firefox → Core
Attached file memory-report.json.gz
Blocks: 1066280
I've suspected this is affecting us on Android too, see bug 1127464. The GL driver fails to allocate and exit()s.
We're tracking this already. It's readback related.
Flags: needinfo?(jgilbert)
Bernhard, can you try this with Firefox 35?  I would like to make sure we're looking at the right regression range here.
Flags: needinfo?(bernhard.robert.pichler)
(In reply to Jeff Gilbert [:jgilbert] from comment #4)
> We're tracking this already. It's readback related.

Is there another bug somewhere?
Possibly bug 1123573?
(In reply to David Major [:dmajor] (UTC+13) from comment #7)
> Possibly bug 1123573?

These likely have the same root cause, but we don't know this yet.
See Also: → 1123573
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #6)
> (In reply to Jeff Gilbert [:jgilbert] from comment #4)
> > We're tracking this already. It's readback related.
> 
> Is there another bug somewhere?

No.
(In reply to Liz Henry :lizzard from comment #5)
> Bernhard, can you try this with Firefox 35?  I would like to make sure we're
> looking at the right regression range here.

Yes i tested it again with Firefox 35.0.1 and it works fine. For some strange reason the demo takes a lot of CPU cycles in Firefox 35 and therefore it's pretty slow, but the memory consumption is stable.
Flags: needinfo?(bernhard.robert.pichler)
(In reply to bernhard.robert.pichler from comment #10)
> (In reply to Liz Henry :lizzard from comment #5)
> > Bernhard, can you try this with Firefox 35?  I would like to make sure we're
> > looking at the right regression range here.
> 
> Yes i tested it again with Firefox 35.0.1 and it works fine. For some
> strange reason the demo takes a lot of CPU cycles in Firefox 35 and
> therefore it's pretty slow, but the memory consumption is stable.

We should be doing less copying in 36+, but it looks like object lifetimes got messed up somehow.
Assignee: nobody → jgilbert
I was very careful to keep this when making CanvasClientSharedSurface. However, without these lines, I do not get leaks anymore, and nothing else seems wrong. Either it isn't necessary or I'm just not hitting the right case.

Asking for extra review here, since I don't really know in-depth what this code does.
Attachment #8570785 - Flags: review?(nical.bugzilla)
Attachment #8570785 - Flags: review?(matt.woodrow)
Attached file testcase
I can reproduce this on Linux with:
browser.tabs.remote.autostart.1 = false (disable e10s)
layers.acceleration.force-enabled = true (enable OGL layers)
webgl.force-layers-readback = true (force readback in CanvasClientSharedSurface)

With non-OGL layers on Linux, I did not see memory growth.
OS: Windows 7 → All
Hardware: x86 → All
You'll have to debug why this was causing a leak, or wait for nical to get back from PTO. I can't see why this code would cause anything to leak.
Attachment #8570785 - Flags: review?(matt.woodrow)
Comment on attachment 8570785 [details] [diff] [review]
no-readback-leaks.diff

Review of attachment 8570785 [details] [diff] [review]:
-----------------------------------------------------------------

This code is (at least partly) related to passing fences around on b2g. It's not clear to me how it is causing a leak, but Sotaro is the person who knows this specific mechanism best, so forwarding the review request to him.
Attachment #8570785 - Flags: review?(nical.bugzilla) → review?(sotaro.ikeda.g)
This code is necessary for b2g. And the bug seems to be fixed by Bug 1136352 that will be soon check in.
Attachment #8570785 - Flags: review?(sotaro.ikeda.g)
(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> This code is necessary for b2g. And the bug seems to be fixed by Bug 1136352
> that will be soon check in.

It is a regression of Bug 1066280. Before Bug 1066280, the related code was called only on gonk.
Comment on attachment 8570785 [details] [diff] [review]
no-readback-leaks.diff

Review of attachment 8570785 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/client/CanvasClient.cpp
@@ -393,5 @@
> -    // RemoveTextureFromCompositableAsync() expects CompositorChild's presence.
> -    GetForwarder()->RemoveTextureFromCompositableAsync(tracker, this, mFrontTex);
> -
> -    mFrontTex = nullptr;
> -  }

We need this code for b2g gonk to prevent Bug 1006164 and Bug 1006957.
Jeff, Sotaro, this is blocking the build 36.0.1. Do you have an eta for this patch? Thanks
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(jgilbert)
Comment on attachment 8571997 [details] [diff] [review]
patch - Disable RemoveTextureFromCompositableTracker except gonk

nical, can you review the patch soon?
Attachment #8571997 - Flags: review?(nical.bugzilla)
Attachment #8571997 - Flags: review?(nical.bugzilla) → review+
Sotaro (or Nical) could you fill an uplift request to aurora, beta & release?
Thanks
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(nical.bugzilla)
Comment on attachment 8571997 [details] [diff] [review]
patch - Disable RemoveTextureFromCompositableTracker except gonk

Approval Request Comment
[Feature/regressing bug #]: Bug 1066280
[User impact if declined]: WebGL/Canvas2d causes memory leak.
[Describe test coverage new/current, TreeHerder]: locally tested.
[Risks and why]: low risk.
[String/UUID change made/needed]: none.
Flags: needinfo?(sotaro.ikeda.g)
Attachment #8571997 - Flags: approval-mozilla-release?
Attachment #8571997 - Flags: approval-mozilla-beta?
Attachment #8571997 - Flags: approval-mozilla-aurora?
Comment on attachment 8571997 [details] [diff] [review]
patch - Disable RemoveTextureFromCompositableTracker except gonk

Approving for release based on irc conversation with Sylvestre.
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(jgilbert)
Attachment #8571997 - Flags: approval-mozilla-release?
Attachment #8571997 - Flags: approval-mozilla-release+
Attachment #8571997 - Flags: approval-mozilla-beta?
Attachment #8571997 - Flags: approval-mozilla-beta+
Attachment #8571997 - Flags: approval-mozilla-aurora?
Attachment #8571997 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/9daf2b5ad7f8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
I was able to easily reproduce the leak using Firefox 36, on Windows 7 x64, with original scenario and attached testcase (and custom prefs from comment 14). The leak no longer showed (for either of the two scenarios) using:
- Firefox 36.0.1 (build2) - BuildID=20150305021524
- latest Firefox 38 Aurora - BuildID=20150305004759
- latest Firefox 39 Nightly - BuildID=20150304030231

For some reason I could not reproduce the original leak on Ubuntu 14.04 x64 or Mac OS X 10.10.
Added to the relnotes "	36.0.1 - Fix an important memory leak (1137251)"
Thanks a lot guys for the quick fix!
Can also confirm the fix on Windows 7 x64 with Firefox 37 Beta 3 build 1.
Status: RESOLVED → VERIFIED
See Also: → 1136352
I started noticing this on firefox 37 with hardware acceleration on linux
I observe frequent large memory leaks with Firefox 37.0.2 & Windows 7.  Let me know if it would be useful to you folks for me to provide you detailed information on the problem.  And, if you're interested, would you please point me to the page that documents how produce the information that is of interest to you(s)?
(In reply to Thurston from comment #39)
> I observe frequent large memory leaks with Firefox 37.0.2 & Windows 7.  Let
> me know if it would be useful to you folks for me to provide you detailed
> information on the problem.  And, if you're interested, would you please
> point me to the page that documents how produce the information that is of
> interest to you(s)?

Please upload a copy of your about:support to this bug.
Per your request please find below a copy of my about:support ...

Application Basics
------------------

Name: Firefox
Version: 37.0.2
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Multiprocess Windows: 0/1

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports (including 2 pending crashes in the given time range)

Extensions
----------

Name: Adblock Plus
Version: 2.6.9
Enabled: true
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

Name: Bookmark Deduplicator
Version: 1.3.1
Enabled: true
ID: bookmarkdeduplicator@foxhatdev

Name: Evernote Web Clipper
Version: 6.0.15
Enabled: true
ID: {E0B8C461-F8FB-49b4-8373-FE32E9252800}

Name: FlashStopper
Version: 1.2.5
Enabled: true
ID: flashstopper@byo.co.il

Name: Memory Restart
Version: 1.18
Enabled: true
ID: memoryrestart@teamextension.com

Name: Show Parent Folder
Version: 2.1
Enabled: true
ID: showParentFolder@alice

Graphics
--------

Adapter Description: ATI Mobility Radeon HD 4250
Adapter Drivers: atiu9p64 atiuxp64 atiuxp64 atiu9pag atiuxpag atiuxpag atiumdva atiumd6a atitmm64
Adapter RAM: 256
Device ID: 0x9712
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 3-29-2010
Driver Version: 8.713.3.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 036e1025
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (ATI Mobility Radeon HD 4250 Direct3D11 vs_4_1 ps_4_1)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 2
browser.places.smartBookmarksVersion: 7
browser.search.useDBForOrder: true
browser.sessionstore.upgradeBackup.latestBuildID: 20150415140819
browser.startup.homepage_override.buildID: 20150415140819
browser.startup.homepage_override.mstone: 37.0.2
browser.tabs.drawInTitlebar: false
browser.tabs.warnOnClose: false
dom.ipc.plugins.timeoutSecs: 10
dom.mozApps.used: true
extensions.lastAppVersion: 37.0.2
font.internaluseonly.changed: false
gfx.direct3d.last_used_feature_level_idx: 0
media.gmp-gmpopenh264.lastUpdate: 1423187886
media.gmp-gmpopenh264.version: 1.3
media.gmp-manager.lastCheck: 1430242814
network.cookie.prefsMigrated: true
places.database.lastMaintenance: 1430242454
places.history.expiration.transient_current_max_pages: 73687
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
print.printer_HP_DeskJet_930C/932C/935C.print_bgcolor: false
print.printer_HP_DeskJet_930C/932C/935C.print_bgimages: false
print.printer_HP_DeskJet_930C/932C/935C.print_colorspace:
print.printer_HP_DeskJet_930C/932C/935C.print_command:
print.printer_HP_DeskJet_930C/932C/935C.print_downloadfonts: false
print.printer_HP_DeskJet_930C/932C/935C.print_duplex: 1515870810
print.printer_HP_DeskJet_930C/932C/935C.print_edge_bottom: 0
print.printer_HP_DeskJet_930C/932C/935C.print_edge_left: 0
print.printer_HP_DeskJet_930C/932C/935C.print_edge_right: 0
print.printer_HP_DeskJet_930C/932C/935C.print_edge_top: 0
print.printer_HP_DeskJet_930C/932C/935C.print_evenpages: true
print.printer_HP_DeskJet_930C/932C/935C.print_in_color: true
print.printer_HP_DeskJet_930C/932C/935C.print_margin_bottom: 0.5
print.printer_HP_DeskJet_930C/932C/935C.print_margin_left: 0.5
print.printer_HP_DeskJet_930C/932C/935C.print_margin_right: 0.5
print.printer_HP_DeskJet_930C/932C/935C.print_margin_top: 0.5
print.printer_HP_DeskJet_930C/932C/935C.print_oddpages: true
print.printer_HP_DeskJet_930C/932C/935C.print_orientation: 0
print.printer_HP_DeskJet_930C/932C/935C.print_page_delay: 50
print.printer_HP_DeskJet_930C/932C/935C.print_paper_data: 1
print.printer_HP_DeskJet_930C/932C/935C.print_paper_height: 11.00
print.printer_HP_DeskJet_930C/932C/935C.print_paper_name:
print.printer_HP_DeskJet_930C/932C/935C.print_paper_size_type: 0
print.printer_HP_DeskJet_930C/932C/935C.print_paper_size_unit: 0
print.printer_HP_DeskJet_930C/932C/935C.print_paper_width: 8.50
print.printer_HP_DeskJet_930C/932C/935C.print_plex_name:
print.printer_HP_DeskJet_930C/932C/935C.print_resolution: 1515870810
print.printer_HP_DeskJet_930C/932C/935C.print_resolution_name:
print.printer_HP_DeskJet_930C/932C/935C.print_reversed: false
print.printer_HP_DeskJet_930C/932C/935C.print_scaling: 1.00
print.printer_HP_DeskJet_930C/932C/935C.print_shrink_to_fit: true
print.printer_HP_DeskJet_930C/932C/935C.print_to_file: false
print.printer_HP_DeskJet_930C/932C/935C.print_unwriteable_margin_bottom: 0
print.printer_HP_DeskJet_930C/932C/935C.print_unwriteable_margin_left: 0
print.printer_HP_DeskJet_930C/932C/935C.print_unwriteable_margin_right: 0
print.printer_HP_DeskJet_930C/932C/935C.print_unwriteable_margin_top: 0
privacy.cpd.cookies: false
privacy.cpd.offlineApps: true
privacy.sanitize.migrateFx3Prefs: true
privacy.sanitize.timeSpan: 0
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1427817800

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.17.4 Basic ECC
Version in use: 3.17.4 Basic ECC

NSSSMIME
Expected minimum version: 3.17.4 Basic ECC
Version in use: 3.17.4 Basic ECC

NSSSSL
Expected minimum version: 3.17.4 Basic ECC
Version in use: 3.17.4 Basic ECC

NSSUTIL
Expected minimum version: 3.17.4
Version in use: 3.17.4

Experimental Features
---------------------
Also, in the state once a lot of memory has been leaked, a saved memory report from about:memory is probably helpful.
I'd send you a memory report produced by:
about:memory -> Show memory reports -> Measure
... except my attempt to send same hit the 64k character limit.
How should I send the the report?
(In reply to Thurston from comment #43)
> I'd send you a memory report produced by:
> about:memory -> Show memory reports -> Measure
> ... except my attempt to send same hit the 64k character limit.
> How should I send the the report?

You can save it to a file and attach the file to this bug. Thanks!
(In reply to timothy from comment #45)
> is there still no fix for this? what is firefox devs doing?
> 
> as soon as version 37 hit  ive had nothing but memory leaks,   after 5 tabs
> are open my firefox starts hitting 2gb -2.5gb of memory, and if i dont
> restart it lags, then crashes, 
> 
> there has been like 2 updates since and still no fix? give me a break v__v i
> hate that i had to solely move to chrome over this v__v

Spamming a fixed bug report will not change anything, it's not a message board. Please, create a new bug report, provide the data from about:support and save a memory log from about:memory with your current profile and a fresh profile.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
(In reply to Loic from comment #46)
> (In reply to timothy from comment #45)
> > is there still no fix for this? what is firefox devs doing?
> > 
> > as soon as version 37 hit  ive had nothing but memory leaks,   after 5 tabs
> > are open my firefox starts hitting 2gb -2.5gb of memory, and if i dont
> > restart it lags, then crashes, 
> > 
> > there has been like 2 updates since and still no fix? give me a break v__v i
> > hate that i had to solely move to chrome over this v__v
> 
> Spamming a fixed bug report will not change anything, it's not a message
> board. Please, create a new bug report, provide the data from about:support
> and save a memory log from about:memory with your current profile and a
> fresh profile.
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles

you obviously dont know what "spamming" is. go back to school please
Please stop this not-related discussion. We will have to restrict this bug otherwise.
1) Attached please find a memory report. "2015-04-29 Memory leak.txt",  produced by:
about:memory -> Show memory reports -> Measure

2) The report, unfortunately, isn't associated with with one of the more clear-cut problems that I've seen in the past.

3) Please let me know if this report isn't suitable and I'll produce one when the leak looks more clear-cut. <Aside: my attempts to reproduce the problem without making my computer unresponsive computer suggest a re-boot is in order.>

4) FWIW: I've been having problems with the "Host Process for Windows Services" process taking-up excessive memory.
(In reply to Thurston from comment #50)
> Created attachment 8599525 [details]
> About:memory showing (hopefully) leak
> 
> 1) Attached please find a memory report. "2015-04-29 Memory leak.txt", 
> produced by:
> about:memory -> Show memory reports -> Measure
> 
> 2) The report, unfortunately, isn't associated with with one of the more
> clear-cut problems that I've seen in the past.
> 
> 3) Please let me know if this report isn't suitable and I'll produce one
> when the leak looks more clear-cut. <Aside: my attempts to reproduce the
> problem without making my computer unresponsive computer suggest a re-boot
> is in order.>
> 
> 4) FWIW: I've been having problems with the "Host Process for Windows
> Services" process taking-up excessive memory.

For #4, it's a windows issue. I've been having this issue for about a month on Windows 7, and I found this:
https://social.technet.microsoft.com/Forums/windows/en-US/4a782e40-bbd8-40b7-869d-68e3dfd1a5b4/windows-update-scan-high-memory-usage
http://blogs.technet.com/b/configurationmgr/archive/2015/04/15/support-tip-configmgr-2012-update-scan-fails-and-causes-incorrect-compliance-status.aspx
I'm running Firefox 39 on a Windows 7 Pro 64bit system and a memory leak is still present.  The memory used grows and grows.  I've run it with Add-ons disabled and the problem persists.  At the moment Firefox is using 797,500K and still growing.  

A memory map gives the warning that
"WARNING: the following values are negative or unreasonably large.

    canvas-2d-pixels 

This indicates a defect in one or more memory reporters. The invalid values are highlighted." 

The highligted entry says:  "-18.28 MB ── canvas-2d-pixels [?!]" with the -18.28 MB in red.
Firefox has had a massive memory leak ever since I can remember.  The developers generally refuse to acknowledge this and just blame addons/plugins.

I just checked mine (v 39) and it was happily sitting on 1.2GB memory usage, which is ridiculous.

"Not Responding" happens incessantly.
Folks, I appreciate that you're still have memory leak issues. Please take some time to file a new bug report describing the issue. Unfortunately there is nothing else we can do in *this* bug report since it has been closed. Thank you.
Same here
Firefox V39
Extensions:
Disconnect 3.15 - enabled
IDM CC 7.3 enable
adobe acrobat - disabled
firebug - disabled
S3-Google translator -disabled
Web developer 1.2 disabled

Appearance:
Simple White 2.2

Initial memory consumption: around 100-300mb
after 2 hours of browsing with always have 2 tabs opened intended for searching it rise memory consumption to 1.2Gb
What does about:memory say when you are in this "bad" state?
 Milan Sreckovic: What does about:memory say when you are in this "bad" state?

"Comments cannot be longer than 65535 characters." 

We cannot post this.  How about you run Firefox yourself, you will see in good time for yourself.
(In reply to developer@suomedia.com from comment #58)
>  Milan Sreckovic: What does about:memory say when you are in this "bad"
> state?
> 
> "Comments cannot be longer than 65535 characters." 
> 
> We cannot post this.  How about you run Firefox yourself, you will see in
> good time for yourself.


Don't post the memory log directy in the message, click on "measure and save", then attach the zipped memory log to the bug report.
(In reply to Loic from comment #59)

> Don't post the memory log directy in the message, click on "measure and
> save", then attach the zipped memory log to the bug report.

There is no option here to attach a file.

Again, I suggest that you yourself simply run Firefox.  It will gobble up a mass of memory in good time and you can look at your own logs.
(In reply to developer@suomedia.com from comment #60)
> (In reply to Loic from comment #59)
> 
> > Don't post the memory log directy in the message, click on "measure and
> > save", then attach the zipped memory log to the bug report.
> 
> There is no option here to attach a file.
> 
> Again, I suggest that you yourself simply run Firefox.  It will gobble up a
> mass of memory in good time and you can look at your own logs.

Does "Add an Attachment" not work?

NB: We all run Firefox daily, and do not encounter the issues that you are describing. Please help us fix the issue you're having.
(In reply to Jeff Gilbert [:jgilbert] from comment #61)
> Does "Add an Attachment" not work?
> 
> NB: We all run Firefox daily, and do not encounter the issues that you are
> describing. Please help us fix the issue you're having.

You run Firefox on what?  I guarantee that if you run Firefox on any version of Windows you will find a massive memory leak.  This has been the case with all versions of Firefox that I have used over many years.

At least now we have gotten past blaming add ons/plugins, which has been the stock response for many years.  Sorry, but I can remove all of these and the memory leak persists.

Sorry, but there is no "Add an attachment button", only "Save Changes".

You guys have had these complaints for years and I think it is high time that you took the time to investigate it yourself.....properly.  Oh, perhaps it works just fine on whatever geek OS you are using, but most people use Windows, as much as you hate it.
Hi developer@suomedia.com,

I understand that you're frustrated with memory leaks in Firefox. Please trust that while we don't *all* run *every* version of *every* operating systems, all operating systems are represented on the wide array of systems people are using across the organization. I ask that you please tone down your language and try to remain calm in Bugzilla. After all, Jeff is only trying to help you.

Regarding "Add an Attachment", you should see this above in the attachments section (above the comments section). Here's a screenshot showing you what we're talking about: http://imgur.com/r6U0Hz0. If you still do not see this I'd be happy to troubleshoot this further but this bug report is not the place to do that. You can email me at ahughes@mozilla.com to talk about this further.

Regarding your memory leak, I asked nicely in comment 55 that anyone coming to this bug report please file a new bug report, so please, file a new bug report. The leak you're experiencing is likely a different case than what was addressed by the patch in this bug and it deserves a separate report so it can be investigated. 

I trust you'll respect this process and the people you're interacting with going forward.

Thank you
developer@suomedia.com and others, in response to the Firefox development team's request, I did open a new bug report, Bug 1181753, on July 5.  I suggest that you add your Memory Save report to that bug.
940 GB with 8 open tabs on Windows 8 (the work machine) (version 40.0.2). If that's not the definition of memory leak, I don't know what is. This poor computer only has 2 GB of RAM so it's barely loafing along
Reasonably complex web pages can easily use 100 MiB each, so that's not massive for 8 tabs, albeit on the high end (I think). Is the memory usage increasing over time? Does it go down if you close one of the tabs? If there *is* a leak, or simply abnormally high memory usage, it might also be caused by an add-on.

For instance, AdBlock Plus used to use a lot of memory, but this was improved by sharing more things in the browser in Firefox 41 (bug 988266). In general, however, high memory usage or memory leaks can have many causes. The one in this bug was fixed, so if you believe you're seeing something abnormal, please open a new bug so it can be tracked separately :)
Stop posting to this thread.

Your problem is not even related to this bug. This thread was about WebGL leaks and is already resolved.
Please use a new bug https://bugzilla.mozilla.org/enter_bug.cgi it is better to file separate bugs as it is impossible to assume all memory issues have the same root cause.
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.