[FFmpeg-devel] Memory leaks in Ffmpeg after changing vlc allocation approach

[Art Clarke]

On Thu, Jun 19, 2008 at 5:44 PM, M?ns Rullg?rd <mans at mansr.com> wrote:

> > I'd be happy to hack this together but wanted to check first:
> > a) is there any other demand for this (if not, I'll just make sure we
>
> I doubt it.

Fair enough (I count that as -1), but does anyone else have a thought?


>
>
> > suppress leaks as they show up in our test suite)?
>
> Suppressing specific messages is easy with valgrind.

Agreed (and as I said, that's my default if folks think this is not worth
addressing).


>
>
> > b) is there any other purposed way to solve this?
>
> Solutions need problems.  There is no problem, and hence there can be
> no solution.


Now this I respectfully disagree with.  You're right that the particular
leak (a static heap allocation) is understood and correctly occurring, and
that it is easy to suppress leaks in valgrind.  As I mentioned originally,
that's what we'll do if folks feel it's the only way around this.

However there is a development philosophy worth considering; once you start
suppressing and explicitly allowing a form of leaking, there is a tendency
for developers to suppress vs. understand errors they see.  My belief and
experience suggests the longer one keeps the philosophy that suppression is
discouraged, the stronger the code remains

Now the obvious counter response is "well then, why don't you keep the
philosophy within Vlideshow that suppressions are bad, and we'll do what we
want on the tip of tree", and, yes, we will.

But Ffmpeg has an opportunity here to keep the zero-leaks philosophy as well
on the tip of tree, which (in my belief) only increases the quality of the
product.  Up until a month ago, Ffmpeg was implicitly living with that
philosophy.  A change to allow static-heap-leaks (and encourage external
testers to suppress them) is fine, but it's worth doing so explicitly than
allowing it to implicitly happen.

$0.02, but it's worth pointing out that:
a) that's in US currency, so it's not worth that much.
b) I defer to you and the other folks who've put way more man hours into
Ffmpeg than I have, so this will be my last comment on this until others
feel like taking up the debate.


>
> > c) does anyone read this far into an e-mail?
>
> No.

Wait... my mind reels at the paradox :)

- Art