Leak with canvas, addEventListener, matchMedia

RESOLVED FIXED

Status

()

Core
Canvas: 2D
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 2 bugs, {mlk, testcase})

Trunk
x86_64
Mac OS X
mlk, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 626343 [details]
testcase

According to trace-refcnt, this testcase makes Firefox leak nsGlobalWindow objects.
I just tried this with a slightly old build (from rev fb6109c9dae5) and that doesn't leak...

I'll try updating.

Comment 2

5 years ago
I can't reproduce this on linux.
OK, rev a4240610972e does show the leak.
And now I see it with rev fb6109c9dae5 too.

My first guess would be that we end up with a cycle through the prescontext somehow, but I dunno exactly how...
Assignee: nobody → continuation
A canvas element is being kept alive here somehow.  My money is on bungled refcounting in nsCanvasRenderingContext2DAzure. ;)

0x12626ded0 [nsGenericElement (xhtml) canvas https://bug757749.bugzilla.mozilla.org/attachment.cgi?id=626343]
    --[[via hash] mListenerManager]-> 0x12674f310 [nsEventListenerManager]
    --[mListeners[i] mListener]-> 0x12549b410 [nsXPCWrappedJS (nsIDOMEventListener)]
    --[mJSObj]-> 0x1184e58c0 [JS Object (Function)]
    --[script]-> 0x1184740e8 [JS Script]
    --[object]-> 0x118470060 [JS Object (Window)]
    --[xpc_GetJSPrivate(obj)]-> 0x126f42ba0 [XPCWrappedNative (Window)]
    --[mIdentity]-> 0x1264d5080 [nsGlobalWindow]

    Root 0x12626ded0 is a ref counted object with 1 unknown edge(s).
    known edges:
       0x126697bc0 [nsGenericElement (xhtml) body https://bug757749.bugzilla.mozilla.org/attachment.cgi?id=626343] --[mAttrsAndChildren[i]]-> 0x12626ded0
       0x1264d3000 [nsCanvasRenderingContext2DAzure] --[mCanvasElement]-> 0x12626ded0
Created attachment 627042 [details]
ref count tree, with balanced subtrees ignored
Whiteboard: [MemShrink]
Created attachment 627053 [details]
refcount tree
The first refcount log shows outstanding refs from the canvas context (expected: they form a cycle), the parent element in the DOM, and what looks like GetCanvasLayer (via CanvasRenderingContext2DUserData)

Is it possible that the canvas layer is leaking for some reason?
(In reply to Boris Zbarsky (:bz) from comment #8)
> Is it possible that the canvas layer is leaking for some reason?
It could be, but it must not be in the CC graph.  That means either that it isn't a CCed class, or it was erroneously dropped.
I really hope layers aren't CCd objects!
The layers aren't CCed.
So isn't this then a dup of ... the one bug where prescontext ends up keeping layers alive
too long.
(or was that fixed?)
(In reply to Olli Pettay [:smaug] from comment #12)
> So isn't this then a dup of ... the one bug where prescontext ends up
> keeping layers alive too long.
Do you have a bug number for that?
I was thinking Bug 731868
That does sound very similar.
Component: DOM → Canvas: 2D
QA Contact: general → canvas.2d
There are (In reply to Boris Zbarsky (:bz) from comment #8)
> Is it possible that the canvas layer is leaking for some reason?
There are 8 Layers leaking.  I'm not sure which is which, though.
I can't reproduce this. Anyone got exact steps to reproduce?
I'm able to reproduce it by just opening the browser with the test case loading as the initial tab, then exiting the browser.  Maybe it is OSX only or something?
Windows and GTK2 nsWindow::Destroy are doing stuff like this:
  if (mLayerManager) {
    mLayerManager->Destroy();
  }
  mLayerManager = nsnull;

I'm guessing nsChildView::Destroy needs that somewhere too. I don't think that's happening right now.
I tried blindly putting that chunk of code into nsChildView::Destroy in a few places but it didn't fix the leak.  Somebody who actually knows some of this code should probably take over from here.
Assignee: continuation → nobody
Ignore the first sentence of the previous comment.  I was managing to edit a different directory from the one I was running.  When I tried it for real, I ended up crashing in the cycle collector on shutdown while tearing down this view stuff:

mozilla::gl::TextureImageCGL::~TextureImageCGL() + 71 (GLContext.h:583)
nsChildView::~nsChildView() + 357 (nsChildView.mm:246)
nsBaseWidget::Release() + 282 (nsBaseWidget.cpp:56)
nsChildView::Release() + 24 (nsChildView.mm:251)
nsPresContext::cycleCollection::Unlink(void*) + 1102 (mozalloc.h:224)

~nsChildView() has some comment about doing some cleanup in case Destroy() hasn't been called, so presumably my random nulling out has upset something there.
Whiteboard: [MemShrink] → [MemShrink:P2]
Depends on: 731868
Fixed in bug 731868. CanvasRenderingContext2DUserData(Azure) no longer has an owning reference to anything.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.