Fix a smart pointer leak.

Fix a smart pointer leak.

R=ben
BUG=run out of VRAM
TEST=open and close many tabs on touch device; VRAM should remain roughly constant

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107618

[mmocny, 2011-10-27 19:02:27]

On 2011/10/27 18:00:26, jonathan.backer wrote:

Confirmed that this fixes the issue, but..

I consider this a smart pointer bug (Perhaps this is a known limitation of
scoped_refptr?) because this should have worked fine.

scoped_refptr::release() doesn't decrement the refcount (via ptr->Release()) yet
assignment/construction increments it.

Thus, release() "leaks" and the object no longer satisfies the invariant
"refcount == #smart pointers referencing it".

There is a possible fix: add a ReleaseButDontDelete() to RefCounted<T> and have
release() call that.

[mmocny, 2011-10-27 19:49:56]

lgtm

On 2011/10/27 19:02:27, mmocny wrote:
> On 2011/10/27 18:00:26, jonathan.backer wrote:
> 
> Confirmed that this fixes the issue, but..
> 
> I consider this a smart pointer bug (Perhaps this is a known limitation of
> scoped_refptr?) because this should have worked fine.
> 
> scoped_refptr::release() doesn't decrement the refcount (via ptr->Release())
yet
> assignment/construction increments it.
> 
> Thus, release() "leaks" and the object no longer satisfies the invariant
> "refcount == #smart pointers referencing it".
> 
> There is a possible fix: add a ReleaseButDontDelete() to RefCounted<T> and
have
> release() call that.

[sky, 2011-10-27 20:49:33]

LGTM

[sky, 2011-10-27 20:54:52]

Seems to me scoped_refptr shouldn't have a release. I wonder if we actually need
it.

  -Scott