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

[Michael Niedermayer]

On Mon, Mar 10, 2008 at 12:11:57AM +0200, Uoti Urpala wrote:
> On Sun, 2008-03-09 at 21:59 +0100, Michael Niedermayer wrote:
> > 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:
> > > > 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.
> 
> Correct for some use, but not for what -Bsymbolic is documented to do.

-Bsymbolic does not do what its documented to do anyway, its not documented
to be incompatible with ANSI/ISO C code.


> 
> > There are 2 further obvious solutions:
> 
> These are a lot bigger changes than what could be called fixing a
> "binutils bug".

Yes its fixing many bugs at once ...


> 
> > 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.
> 
> It's normal for an application not to have its whole code in RAM. If you
> do the relocations at once when starting then the whole image needs to
> be loaded from disk to RAM before starting, and then unneeded portions
> must later be written to swap to free the RAM. This both significantly
> slows startup and generates extra disk IO. 

Loading the whole app is much faster than loading pages on demand. Simply
because the maybe 20mb a larger app has can be read quite quickly. Loading
it all as 4kb pages as they are accessed (with a 10ms seek for each on a
fast HD) will take much longer.


> If you try to do relocations
> on demand when loading pages from disk then you must keep a data
> structure that allows quickly identifying all needed relocations on any
> page.

For example a linked list:

i= get_initial_ptr_for_page_from_locked_mem(page_id);
while(i<1024){
    unsigened int p=((uint32_t*)page)[i];
    i= p & 2047;
    ((uint32_t*)page)[i]= GOT[p>>11];
}

This is O(num of relocs), thus many orders of magnitude faster than disk IO.

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- 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/20080310/23e368a1/attachment.pgp>