Closed
Bug 637449
Opened 14 years ago
Closed 13 years ago
WebGL websites do not release memory after being closed
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 746009
People
(Reporter: ben.r.xiao, Unassigned)
References
()
Details
(Keywords: memory-leak, Whiteboard: [MemShrink:P2])
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110228 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110228 Firefox/4.0b13pre
The Flight of the Navigator WebGL demo does not release all memory after being closed. Neither does the Yo Frankie WebGL demo (http://www.glge.org/demos/frankiedemo/).
Both demos increase memory usage by 50 MB.
Reproducible: Always
Steps to Reproduce:
1. Run either WebGL demos
2. Close tab
3. Notice memory usage has jumped 50 MB
Actual Results:
Some memory is not freed after closing the WebGL page
Expected Results:
All memory is freed after closing the WebGL page.
Reporter | ||
Updated•14 years ago
|
Version: unspecified → Trunk
Comment 1•14 years ago
|
||
Reproduceable on:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre
*Note: Wouldn't be this related/similar to the issues reported in the Bug 631494 ?
The memory jumps while playing, but after the tab is closed, each time flushes to a no more than 200 mb level.
Updated•14 years ago
|
Product: Firefox → Core
QA Contact: general → general
Updated•14 years ago
|
Component: General → Graphics
QA Contact: general → thebes
Comment 2•14 years ago
|
||
After you close a WebGL tab, the WebGL context object that it uses becomes unreferenced. It will then become freed whenever the JavaScript engine runs its garbage collector.
It is a known issue that unreferenced WebGL contexts are often kept around for quite long before garbage collection actually takes place: see bug 617453.
However, that in itself is not really a bug. It's up to the JS engine to decide when to garbage-collect.
Do you have evidence that anything else than that is happening?
Reporter | ||
Comment 3•14 years ago
|
||
How big are these WebGL contexts? I am literally seeing around 50 MB increases every WebGL page I run and this is unacceptable.
Isn't it pretty trivial to detect when a tab with a WebGL context closes and free that WebGL context?
Comment 4•14 years ago
|
||
(In reply to comment #3)
> How big are these WebGL contexts? I am literally seeing around 50 MB increases
> every WebGL page I run and this is unacceptable.
It depends on what the WebGL app did. It could be 50 MB if the WebGL app used big textures or geometric data.
What you say raises a few questions:
* how long after does this increased memory usage stay around?
* how do you measure this memory usage? (this is really hard to measure reliably) Why do you trust these values?
* Are that it's Firefox who's responsible for it and not, say, your operating system?
>
> Isn't it pretty trivial to detect when a tab with a WebGL context closes and
> free that WebGL context?
I asked this in bug 613494. It doesn't seem trivial at all. But these unused WebGL contexts go away after a while (they should definitely go away quickly if you keep using your browser on other pages, especially on other memory-intensive pages, as the JavaScript engine will eventually garbage-collect dead objects).
Comment 5•14 years ago
|
||
> Isn't it pretty trivial to detect when a tab with a WebGL context closes and
> free that WebGL context?
No, because the context can still be used from script even if the tab is closed, as long as script has a reference to it. And detecting whether script has a reference involves a gc (and actually a cycle collection in this case).
We do plan to make garbage collection more aggressive, and moving to a multi-process architecture will help with the tab-closing thing. So not all is lost; it'll just take a few months.
Comment 6•14 years ago
|
||
(In reply to comment #5)
> > Isn't it pretty trivial to detect when a tab with a WebGL context closes and
> > free that WebGL context?
>
> No, because the context can still be used from script even if the tab is
> closed, as long as script has a reference to it. And detecting whether script
> has a reference involves a gc (and actually a cycle collection in this case).
Boris, thanks for this explanation, that's what I was not getting.
Reporter | ||
Comment 7•14 years ago
|
||
(In reply to comment #4)
> What you say raises a few questions:
> * how long after does this increased memory usage stay around?
> * how do you measure this memory usage? (this is really hard to measure
> reliably) Why do you trust these values?
> * Are that it's Firefox who's responsible for it and not, say, your operating
> system?
Well, here's what I did. I ran flight of the navigator and the yo frankie demo. Memory usage increased to about 700 MB. I closed the demos, the memory usage dropped to around 450 MB. I waited for an hour, browsed some other websites, and looked again at my memory usage and it was still around 450 MB. There had to be a GC somewhere within that hour no?
Is there anyway I can force a gc? I tried running your code in the web console, Benoit
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
window.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
.getInterface(Components.interfaces.nsIDOMWindowUtils)
.garbageCollect();
but it gave me privilege errors so I am pretty sure I am not supposed to use it in the console. How did you run it?
Comment 8•14 years ago
|
||
Try error console - the web console runs with the security privilege of the current web page.
Reporter | ||
Comment 9•14 years ago
|
||
I pasted the code in the error console and it doesn't seem to be doing anything. Nothing is being displayed and memory usage is not going down.
Comment 10•14 years ago
|
||
I just put that in a <script> in a html page and loaded it. But that was a file:// URL.
Comment 11•14 years ago
|
||
(In reply to comment #7)
> (In reply to comment #4)
> > What you say raises a few questions:
> > * how long after does this increased memory usage stay around?
> > * how do you measure this memory usage? (this is really hard to measure
> > reliably) Why do you trust these values?
> > * Are that it's Firefox who's responsible for it and not, say, your operating
> > system?
>
> Well, here's what I did. I ran flight of the navigator and the yo frankie demo.
> Memory usage increased to about 700 MB. I closed the demos, the memory usage
> dropped to around 450 MB. I waited for an hour, browsed some other websites,
> and looked again at my memory usage and it was still around 450 MB. There had
> to be a GC somewhere within that hour no?
Surely there had. But you have to realize that on modern OSes, 'measuring memory usage' is very tricky. There's no single metric that you could look up that would tell you the answer.
Reporter | ||
Comment 12•14 years ago
|
||
Well, if you look at Firefox 3.6 and Chrome on the same operating system, their memory usages are comparatively low. What the Windows Task manager reports is what the operating system sees and it will allocate memory for other applications around that.
Even if Firefox 4 was simply allocating more RAM than it needs for caching and memory fragmentation purposes, it is still not usable by other applications on the OS.
Reporter | ||
Comment 13•14 years ago
|
||
So I put a html file on my desktop with the following contents
<html>
<head>
<script type="text/javascript">
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils).garbageCollect();
</script>
</head>
<body>
</body>
</html>
When I opened the file, Firefox warned me that a script was requesting elevated permissions. I clicked Allow and memory usage did not decrease.
I ran flight of the navigator and Yo Frankie. Closing them gave me a memory usage of 350 MB. I ran the script, memory usage did not change.
Updated•14 years ago
|
Comment 14•14 years ago
|
||
OK, so, this is interesting. Let's admit for a moment that there's a real leak here. There are 4 layers involved here:
WebGL code in Firefox ---> ANGLE ---> Direct3D ---> Direct3D Driver
The leak could be at any level there. Fortunately, you can replace this chain by
WebGL code in Firefox ---> OpenGL ---> OpenGL driver
by going to about:config and setting webgl.prefer-native-gl=true. If you have a ATI or Intel card, you will also have to set webgl.force-enabled=true because we block ATI and Intel drivers.
Does this make a difference?
- if yes, the most likely hypothesis becomes a leak in ANGLE.
- if no, then I'll start worrying that there may be a leak in our own code.
Comment 15•14 years ago
|
||
@ Boris: do you know if such system memory stats are meaningful at all wrt possible leaks? I don't realize the implications of e.g. jemalloc mmapping memory blocks --- would that show up as "used memory"?
Comment 16•14 years ago
|
||
Benoit, I don't know....
Reporter | ||
Comment 17•14 years ago
|
||
I tested with webgl.prefer-native-gl=true and it still does not free memory.
Comment 18•14 years ago
|
||
@ Benjamin:
when you have webgl.prefer-native-gl=true, in about:support, what does WebGL renderer say?
Reporter | ||
Comment 19•14 years ago
|
||
NVIDIA Corporation -- GeForce 9600M GT/PCI/SSE2 -- 3.3.0
Comment 20•14 years ago
|
||
So, indeed, this is using your OpenGL driver instead of ANGLE.
I will run this in valgrind with a software renderer to see if there is a leak in our WebGL implementation code.
What is the *smallest* WebGL site on which you are seeing a clear and persistent memory usage increase? Asking because running in valgrind is very slow.
Reporter | ||
Comment 21•14 years ago
|
||
Smallest site I can find: http://www.glge.org/demos/hair/
Memory usage started at 150 MB. After 2 runs of the hair demo memory usage went up to 180 MB and won't go back down.
Comment 22•14 years ago
|
||
(In reply to comment #21)
> Smallest site I can find: http://www.glge.org/demos/hair/
Currently valgrinding this. Using the NVIDIA driver because OSMesa is apparently not able to run this demo (takes forever to render the first frame).
Details about the procedure are given at:
https://bugzilla.mozilla.org/show_bug.cgi?id=588918#c21
Comment 23•14 years ago
|
||
Valgrind didn't find anything here that could explain the 50 MB leak. We really should try to find a OSMesa-proof demo. I will try with bug 651695.
Updated•14 years ago
|
Blocks: mlk-fx4-beta
Updated•14 years ago
|
Whiteboard: [MemShrink:P2]
Updated•13 years ago
|
QA Contact: thebes → bjacob
Comment 24•13 years ago
|
||
Is this still reproducible in Nightly?
Comment 25•13 years ago
|
||
This smells very much like memory fragmentation, so duping.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•