[FFmpeg-devel] Memory leak using bitstream filters with shared libs
Tue Mar 11 23:54:24 CET 2008
On Wed, Mar 12, 2008 at 12:13:08AM +0200, Uoti Urpala wrote:
> > 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?
If the user asks ffmpeg to lets say mux msmpeg4v3 in mpeg-ps then thats
what she asked for and what she gets standard conformant or not.
OTOH if she asked ffmpeg to generate intra only video and store it in
mpeg-ps and she then got huffyuv in mpeg-ps while otherwise she would have
gotten mpeg2 in mpeg-ps then yes this would be a bug.
Intra only does not implicate breaking the standard.
Similarly -Bsymbolic does not implicate that the application would not
see the same symbols. Its an effect of the implementation not anything
required by binding symbols in the lib to the ones in the lib.
> > > 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.
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.
> 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.
> > > 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
Or maybe you are the only one who didnt ...
> 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.
We all wondered why its not default, now we know, its buggy.
> 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel