Michael Niedermayer <[email protected]> added the comment: On Sat, Aug 15, 2009 at 11:11:07AM +0000, Reimar Döffinger wrote: > On Sat, Aug 15, 2009 at 10:56:13AM +0000, Carl Eugen Hoyos wrote: > > If Reimar is right (and I don't doubt it), the issue should be closed. > > In principle yes, but I do not know the exact reason for this report. > There might be a documentation issue: > If an OS (e.g. Windows) allows you to unload a shared library, this memory > will > indeed be lost forever if you unload libavcodec (which is what would > make it a real leak, not just allocated memory that just isn't used > right now). > It might be good to explicitly state somewhere appropriate that > unloading is not (and probably never will be) supported by FFmpeg.
> Though it might not be that hard to add a function that frees all > that statically allocated memory (obviously, that function would > not be thread-safe and would need external locking). we tried that (without locking), it didnt work (obviously), we removed it again. The solution(tm) is to NEVER malloc() static arrays, it is NEVER needed. find out what size the malloc is and put that in the source, add an assert() to make sure it really matches and the problem is solved. michael, who is barely able to keep up with telling people not to redo silly things or undo others that have been done correctly but arent understood ... [...] -- GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator _____________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1323> _____________________________________________________
