[FFmpeg-devel] Memory leak using bitstream filters with shared libs

[Uoti Urpala]

On Tue, 2008-03-11 at 23:54 +0100, Michael Niedermayer wrote:
> On Wed, Mar 12, 2008 at 12:13:08AM +0200, Uoti Urpala wrote:
> > Binutils has no way around the "can't keep them the same if you change
> > them" problem even if it assumes that there are no alternative
> > definitions in other objects.
> 
> This does not affect that it is required by C. And as such is a bug
> whereever one now pushes it, be it binutils, the docs or the whole design
> of the ELF GNU toolchain.

The C standard does not require that tools have no options to generate
nonstandard behavior. The only "fix" that can be done in practice is
warn more clearly about the side effects in the documentation.

> > If the main program has copy relocations
> > of data variables then it is not possible for the library code to
> > guarantee both using the same address as the main program (which implies
> > using the copy relocation) and using the library's own definition of the
> > variable (which implies NOT using the copy relocation).
> 
> Your reasoning is based on keeping everything constant except the generated
> library. Get rid of copy relocations and its solved.

Sure, if you redesign the whole x86 ABI then it's possible to have both.
That's not a very realistic solution for FFmpeg's problems though.

Actually there seems to be some movement toward PIE (position
independent executable, compiling everything including the main program
with -fPIC). Such programs won't use copy relocations. I'm not sure
you'll be otherwise happy about that direction though...

> > If someone posted similar complaints about FFmpeg, for example "We tried
> > giving various nonstandard options to FFmpeg and the resulting file
> > doesn't play in my DVD player any more! That's a horrible bug!" they'd
> > surely be flamed. Even if FFmpeg documentation was less than perfect.
> > Your complaints about -Bsymbolic aren't really any more valid than that.
> 
> As said the fine difference is that explicitly asking to break the standard
> and asking to do something unrelated to standard breakage which does _NOT_
> require breaking the standard break it are 2 very different things.

And just how would you implement -Bsymbolic so that it binds symbols to
the versions in the library but never makes the addresses differ from
those seen elsewhere? "Rewrite the ABI for the sake of this option" is
not a realistic answer IMO.