Closed Bug 1256946 Opened 8 years ago Closed 8 years ago

test_video_wakelock.html leaks textures on Windows e10s debug builds

Categories

(Core :: Graphics: Layers, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1252677
Tracking Status
e10s + ---
firefox48 --- affected

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [e10s-orangeblockers][gfx-noted])

dom/html/test/test_video_wakelock.html leaks 3 PTextureChild things when run on Windows with e10s. This is a DOM test, but I'm going to assume the leak is due to a graphics issue with video or something. Bug 1255891 covers some other tests that leak textures.
Whiteboard: [MemShrink]
is this a shutdown leak?
Blocks: e10s-tests
Flags: needinfo?(continuation)
Looks like it started leaking more in the last day or so.
https://treeherder.mozilla.org/logviewer.html#?job_id=156216&repo=ash
https://treeherder.mozilla.org/logviewer.html#?job_id=156291&repo=ash
Whiteboard: [MemShrink] → [MemShrink][e10s-orangeblockers]
(In reply to Jim Mathies [:jimm] from comment #1)
> is this a shutdown leak?

It leaks through shutdown, yes. This is detected by the XPCOM shutdown leak detector, and the leak is in the content process.
Flags: needinfo?(continuation)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #2)
> Looks like it started leaking more in the last day or so.
> https://treeherder.mozilla.org/logviewer.html#?job_id=156216&repo=ash
> https://treeherder.mozilla.org/logviewer.html#?job_id=156291&repo=ash

As I mentioned to Ryan in IRC, these appear to be new leaks, because they are occurring in a separate directory. I'll file a new bug for them once I figure out what test is causing this.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #2)
> Looks like it started leaking more in the last day or so.
> https://treeherder.mozilla.org/logviewer.html#?job_id=156216&repo=ash
> https://treeherder.mozilla.org/logviewer.html#?job_id=156291&repo=ash

I filed bug 1258113 for that leak.
Looks like this morphed into a WeakReference<MessageListener> leak now.
https://treeherder.mozilla.org/logviewer.html#?job_id=18334585&repo=try
https://treeherder.mozilla.org/logviewer.html#?job_id=18334569&repo=try
https://treeherder.mozilla.org/logviewer.html#?job_id=18334609&repo=try

I added leak stack checking to that Try push, but given the number of WeakReference<MessageListener> leaks, I'm not sure which stack is the right one.
WeakReference<MessageListener> is a generic superclass for IPC data structures. This may be a general increase across all tests in the number that we are leaking (due to ImageBridgeChild, say), and this test may go orange because it is the only one to exceed the very high threshold I have landed to try to green up these tests.
Whiteboard: [MemShrink][e10s-orangeblockers] → [e10s-orangeblockers]
Whiteboard: [e10s-orangeblockers] → [e10s-orangeblockers][gfx-noted]
This seems to be the same as bug 1252677, which Bas is near to having a fix for.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.