WebGL resources are leaked when a page is reloaded

RESOLVED INCOMPLETE

Status

()

defect
RESOLVED INCOMPLETE
7 years ago
4 years ago

People

(Reporter: cwiiis, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Trunk
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [games:p2])

Reporter

Description

7 years ago
If you load a page with a WebGL demo in Firefox Mobile, it appears that reloading does not free the resources associated with WebGL. Reloading multiple times will cause odd behaviour and crashing in fairly short order.

This may be a duplicate of bug #725145.
Reporter

Updated

7 years ago
Blocks: gecko-games
How are you determining that resources are not being freed?
Reporter

Comment 2

7 years ago
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #1)
> How are you determining that resources are not being freed?

Not by any scientific means, but after a couple of reloads, texture/buffer creation starts to fail (so some may work fine, but once a certain point is reached, all fail), and usually after they fail, a further reload results in a crash. Not sure what else could cause this.

This is only on mobile, and I've only tested on a Galaxy Nexus. Desktop appears to be fine.
Might be a good time to check and make sure we have COUNT_CTOR all over our webgl code.
Well, GL resources all get destroyed when the context is destroyed (assuming no gl context sharing).  Now, that context destruction is dependent upon GC, but still...
jgilbert, bjacob, or maybe benwa -- can one of you guys take a look at this and see if there's anything here?  I suspect this is just an issue of GC not firing enough during WebGL code, and it might have been fixed with bjacob's per-origin context counting stuff.
Whiteboard: [games:p2]
Any update on seeing if this is an issue?
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #6)
> Any update on seeing if this is an issue?

No. I have some patches somewhere to redo the memory tracking for GL objects in a more robust spec-matching way.

I suspect comment#5 is correct in that the force-lose-context for many living GL contexts should alleviate this, but cannot by-itself wholly solve this.
Did the stuff in comment 7 ever land? If so, is there more that needs to be done here? Any other bugs that this depends on?
Flags: needinfo?(jgilbert)
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jgilbert)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.