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

[Uoti Urpala]

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.

> There are 2 further obvious solutions:

These are a lot bigger changes than what could be called fixing a
"binutils bug".

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

There would also be other practical problems but this is going pretty
far into hypothetical behavior that no one will implement anyway...