[FFmpeg-trac] #4819(avcodec:reopened): av_register_all() memory leak

[FFmpeg]

#4819: av_register_all() memory leak
--------------------------------------+------------------------------------
             Reporter:  joeallen      |                    Owner:
                 Type:  defect        |                   Status:  reopened
             Priority:  normal        |                Component:  avcodec
              Version:  unspecified   |               Resolution:
             Keywords:  libx265 leak  |               Blocked By:
             Blocking:                |  Reproduced by developer:  0
Analyzed by developer:  0             |
--------------------------------------+------------------------------------

Comment (by cehoyos):

 Replying to [comment:12 Cigaes]:
 > Replying to [comment:10 joeallen]:
 > > Also just to throw this out there: avfilter_register_all() also leaks
 additional 49 bytes. Eventually I am gonna have multiple instances(1K+) of
 this conversion application that I am making so those bytes would add up.
 >
 > > {{{
 > > ==6024==    still reachable: 130 bytes in 3 blocks
 > > }}}
 >
 > Do you realize that “still reachable” means that the memory is not
 leaked, it is definitely allocated, because it is needed? Do you also
 realize that modern operating systems free all allocated memory when a
 process exit?
 >
 > Therefore, freeing these 130 octets will only make a practical
 difference if your “1K+” instances all finish in the same millisecond and
 another very expensive application starts requiring memory in the small
 interval before they exit. Not very likely, to say the least.
 >
 > Furthermore, since memory allocation is made by 4k pages at the process
 level, freeing 130 octets will likely make no difference at all.
 >
 > Last of all, these 130 octets are needed during the works of the
 library. If the library were changed to allow freeing them, they still
 would be needed when it is in use. Actually, avoiding global state would
 likely ''increase'' the memory use marginally, due to the use of an extra
 indirection.
 >
 > In short: you are barking at the wrong tree.
 >
 > Note that I am all in favour of removing all global allocated state. But
 not due to valgrind's output, it is currently satisfactory. The good
 reason would be API cleanliness, and it would warrant the small extra
 memory requirement.

 This all sounds to me as if you would argue that the "leak" (if there is a
 leak) could be fixed but it is not worth the effort.
 I believe the "leak" (if it exists) cannot be fixed because there is no
 way to free the resources allocated by dl_open() from the process calling
 dl_open() - from valgrind's pov.

 But maybe I am missing something and somebody can explain how I am wrong?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4819#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker