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

[Michael Niedermayer]

On Sun, Mar 09, 2008 at 08:11:58PM +0200, Uoti Urpala wrote:
> 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.

Now while this is off topic, avoiding writable+executable memory by having
function pointers writeable and in a well known location does not help
security much. The GOT by all means should be read only after loading.
But again this isnt what we are discussing in this thread ...


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

First there is richs suggestion of simply only binding calls but not "address
of" to local code when -Bsymbolic is used. This is simple, practical and correct
even if it isnt the best solution.

There are 2 further obvious solutions:
1.
Is that an application would have all spots in it
which use addresses of symbols be corrected during loading. This is surely
faster than the disk from which it is loaded thus no performance penalty
compared to a single table of such indirections.
If the application is loaded a 2nd time then the memory layout of the first
is simply duplicated, so that all libs are at the same spot, not a single
text-rel needs to be done here and not a single page from any
lib or the app, PIC or not would be duplicated, they all can be shared.
The only possible performance penalty would be that the relocations need
to be either written to disk in case of page outs or be done during page
ins, though i suspect that again disk IO is more limiting than updating
the addresses.

2.
Would be quite similar to above, the difference would be that symbol
addresses would be resolved during prelinking so that no further changes
to pages are needed at all during loading or page ins.
This system could also fall back to above if new libs had been installed
after prelinking.

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

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/4750a964/attachment.pgp>