[webkit-dev] Reference count leak with InBandTextTracks?

[Jer Noble]

On Oct 1, 2013, at 2:48 AM, Benjamin Dupont (bedupont) <bedupont at cisco.com> wrote:

> Hi all,
>  
> I am currently working on the InbandTextTracks in webkit and I am trying to understand how the memory is released.
>  
> When we launch the track-in-band.html layout test, two in-band text tracks have been created and added, the corresponding RefPtr has a refCount equals to three.
> 1. Why are there 3 owners for each in-band text track? Is there an hidden cache mechanism?

The tracks are being referenced by the JavaScript running in the test page.

> After this test, if we load another page, the player is destroyed and the clearTextTracks method is called.
> In my understanding, the player should be the only owner of in-band text tracks and thus after the clearTextTracks method is called, the ref count should be decreased to 0 and the in-band text track object should be deleted.

Your understanding is incorrect.  Each track is also referenced by the JSTextTrack wrapper created when referencing videoElement.textTracks[].  Furthermore, those wrappers are stored off as variables inbandTrack{1,2,3,4} in the global context, so they won't be destroyed by GC until the window object is destroyed

> In fact, after the clearTextTracks method the ref count isn’t equals to 0 thus the in-band text track object isn’t deleted.
> This text track object is deleted when the clear memory cache is called.
>  
> 2. Is it a normal behavior? If yes, what is the interest to use smart pointer?

Yes.

> 3. How does the clear memory cache know that this ref pointer (with a ref count != 0) can be released? 

This is precisely the point of using a smart pointer; since the track is still being referenced, it won't be deleted until that refcount drops to 0.

-Jer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131001/c74db323/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1234 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131001/c74db323/attachment.p7s>