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

[Michael Niedermayer]

On Sun, Mar 09, 2008 at 06:37:01AM +0200, Uoti Urpala wrote:
> On Sun, 2008-03-09 at 04:25 +0100, Michael Niedermayer wrote:
> > On Sun, Mar 09, 2008 at 04:48:11AM +0200, Uoti Urpala wrote:
> > > On Sat, 2008-03-08 at 19:23 -0500, Rich Felker wrote:
> > > > It's actually an implementation bug since the C language requires that
> > > > the addresses match. I suspect it's binutils doing something stupid
> > > > due to -Bsymbolic. Anyway this sort of problem is common enough that
> > > 
> > > It's binutils doing what -Bsymbolic is documented to do - binding
> > > references to global symbols to the definition within the shared
> > > library. If the main program is compiled without -fPIC then functions
> > > are normally bound to the main program's PLT entry (if one exists for
> > > the function in question), and that's what other code will use.
> > 
> > "binding references to global symbols to the definition within the shared
> > library" is one thing and thats fine. The bug is that the references from
> > outside the shared lib bind to something else.
> 
> The "bug" is that references in different places bind to different
> targets. You can't say that changing references in one place to point to
> a different target is "fine" if you also care about all references being
> in sync.
> 
> > Its not allowed by the c
> > standard as others have already said and not documented as side effect
> > of -Bsymbolic.
> 
> If you want behavior as closely matching the C standard as possible then
> don't use -Bsymbolic. There's not much else it could do - you can't both
> change reference targets in one place AND keep them in sync with other
> places! 

> Any attempt to make -Bsymbolic also change the addresses seen by
> a non-PIC main program would need to involve things like adding
> relocations to be done at runtime to the main program code with values
> depending on shared library contents...

Curently AFAIK the address is written in the PLT or the PLT reads it
from the GOT in the case you describe, thus
in some sense the PLT contains hundreads of relocations. Instead of
updating the addresses in these tables the actually used addresses in the
program should be updated, it would be one layer of indirection less and
be much more efficient as well. Besides that it would conform to the C
standard with -Bsymbolic.


> 
> The (at least somewhat) practical alternatives I can think of are:
> 1. Accept that addresses inside and outside the library will not match
> 2. Stop using -Bsymbolic (you can still use visibility to bind
> non-public symbols inside the library)
> 3. Compile everything with -fPIC, even the program using the library

True, these are the things we can do still i consider these workarounds of
a bug in binutils.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080309/b18de379/attachment.pgp>