[FFmpeg-devel] [PATCH] [Trac ticket #3194] libavcodec/utils: Statically initialize global mutexes to avoid a leak.

Tomer Barletz barletz at gmail.com
Mon Dec 16 07:26:55 CET 2013

On Sun, Dec 15, 2013 at 11:49 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Sun, Dec 15, 2013 at 01:44:51PM +0100, Hendrik Leppkes wrote:
> ...
> > The real problem here is that apparently you can't rely on the close
> > callback being called on the lockmgr. If an user app provides its own,
> > it could also leak.
> > So why is this not called?
> how / where do you want to call it ?
> explicitly by the user app only ?
> in that case libs that use libavcodec will leak
> by every lib that uses libavcodec ?
> this will lead to a races
> so it first would need some kind of reference counting
> where all libs & apps using libavcodec would call some function at
> the end and when the count reaches 0 the mutexes could be
> deallocated, but thats still tricky as one has to consider races where
> another lib starts using libavcodec in that very moment
> so 100% safe and robust deallocation seems tricky
> if these corner cases dont bother you, you can just register
> NULL as lock manager at the end to cause the mutexes to be freed
> [...]
I think that the real problem is the fact that a global mutex is used in a
utility function, and it looks like the code was forced into a single
initialization routine, but the uninitialization part is missing.
I think this code belongs somewhere else, or we should have a single
init/uninit calls that will always be called once, like Michael suggests


More information about the ffmpeg-devel mailing list