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

[Uoti Urpala]

On Sun, 2008-03-09 at 14:14 +0100, Michael Niedermayer wrote:
> On Sun, Mar 09, 2008 at 06:37:01AM +0200, Uoti Urpala wrote:
> > 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

PLT has "jmp *X". Initially the value at X points to a function to do
runtime lookup for the function in question. When called for the first
time this function writes the lookup result at X.

It would be slightly faster to have a direct jump "jmp Y" in the PLT
instead (and modify the value Y in the code), but this is not done to
avoid having a writable+executable memory area.

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

Handling all symbols that way would require keeping track of a huge
number of relocations. It would require the code pages to be writable,
and modifying the pages would prevent sharing them between processes.
Doing a relocation of every library function call (and touching every
code page) in a big program at startup would give bad startup
performance, and doing on-demand lookup of every call site (as opposed
to every called function) would be inefficient.

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

Can you even specify what "less buggy" behavior would be and how it
would differ? (I don't think that your "modify code everywhere to do
relocations" above is an answer as binutils alone could not do that,
even if it were doable otherwise).