Canvas uses a WeakPtr in its release callback, so if it destroys itself while the display compositor is still holding the texture resource, by the time it is returned, nothing calls DeleteTexture() on it.
Pepper has the same problem but we think it would destroy the context on shutdown (unlike canvas which uses the long-lived main thread shared context), which would free the resources.
Assigned to me, but feel free to take it.
2 possible ways to fix canvas:
1. Keep the canvas structures alive with refcount from the release callback, so they can delete the texture always.
2. Insert a free-methods ReleaseCallback in before it gets to the canvas code, that checks the weakptr, and has a ref on the context, and deletes the texture if the weakptr is null so it can't pass it on to the canvas code.
Comment 1 by danakj@chromium.org
, Sep 25 2017