[webkit-dev] Reference count leak with InBandTextTracks?

[Benjamin Dupont (bedupont)]

Thanks Jer and Brendan for your explanations.

De : Jer Noble [mailto:jer.noble at apple.com]
Envoyé : mardi 1 octobre 2013 17:47
À : Benjamin Dupont (bedupont)
Cc : webkit-dev at lists.webkit.org
Objet : Re: [webkit-dev] Reference count leak with InBandTextTracks?


On Oct 1, 2013, at 2:48 AM, Benjamin Dupont (bedupont) <bedupont at cisco.com<mailto: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/20131002/f042a52f/attachment-0001.html>