[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 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.

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