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

[Uoti Urpala]

On Tue, 2008-03-11 at 21:14 +0100, Michael Niedermayer wrote:
> On Tue, Mar 11, 2008 at 09:20:06PM +0200, Uoti Urpala wrote:
> > On Tue, 2008-03-11 at 18:52 +0100, Michael Niedermayer wrote:
> > > I guess i should refuse a workaround until the bug has been reported, maybe
> > > they do fix it. But even if not it should be reported.
> > 
> > And what is the "bug"? That you can't both change what the symbols are
> > bound to AND keep them the same to match what they're bound to
> > elsewhere? I wouldn't expect a fix for that dilemma...
> 
> There is just one symbol and that is in the library
> -Bsymbolic as it is documented removes the special feature of ELF shared
> libs to override such symbols.

I think the expected use case is some kind of "poor man's visibility
support". The documentation only talks from the viewpoint of internal
symbols, and doesn't explain the resulting side effects on symbols that
are meant to be public.

>  The C standard (as well as common sense)
> requires all references to the symbol to be equal. This is not optional
> or dependant on command line options. Its a strict requirement of C.
> The bug is that this requirement is broken when the lib is compiled with
> PIC and -Bsymbolic and the main app is not compiled with PIC.

So if someone manages to generate a video stream with FFmpeg which
violates any standard that must be a bug in FFmpeg and the options which
make it possible must be removed?

> > but don't expect them to change the documented semantics
> > of -Bsymbolic. 
> 
> Where is that documentation which says that the main app will see a different
> symbol than the lib with -Bsymbolic. Its certainly not in the documentation of
> -Bsymbolic, as such these are not the "documented semantics".

It is not in itself directly guaranteed behavior (in the sense that you
can't RELY on the symbol address being different in the library and in
the main program). However it is often a consequence of the documented
behavior. You cannot both change the bindings in the library and keep
them the same as in the main program.

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

> > If you want another option that does something different
> > that's a separate feature request, not a bugfix.
> 
> I wonder why you cannot just accept that you were wrong ...

I'm the only poster in this thread who has consistently understood the
issues. OTOH you earlier posted things like "Mans added -Bsymbolic,
everyone wonders why this isnt default and what the ELF designers were
smoking" in your blog. Now you cannot admit that you had no idea what
you were talking about, and are trying to find other people to blame.

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.