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

[Michael Niedermayer]

On Wed, Mar 12, 2008 at 01:42:39AM +0200, Uoti Urpala wrote:
[...]
> > > If the main program has copy relocations
> > > of data variables then it is not possible for the library code to
> > > guarantee both using the same address as the main program (which implies
> > > using the copy relocation) and using the library's own definition of the
> > > variable (which implies NOT using the copy relocation).
> > 
> > Your reasoning is based on keeping everything constant except the generated
> > library. Get rid of copy relocations and its solved.
> 
> Sure, if you redesign the whole x86 ABI then it's possible to have both.
> That's not a very realistic solution for FFmpeg's problems though.

I agree with you that its not realistic that the gnu toolchain maintainers
will correct this, my argument was that it can be done in priciple and that
the final implementation would be superior in many other ways besides this
bugfix.


> 
> Actually there seems to be some movement toward PIE (position
> independent executable, compiling everything including the main program
> with -fPIC). Such programs won't use copy relocations. I'm not sure
> you'll be otherwise happy about that direction though...

My oppinion about PIE is somewhat mixed. Its certainly a stupid idea for
performance relevant code. Though it might have some small security benefit
for security relevant code, though ironically ive just a few days ago read
a paper describing how to exploit a buffer overflow in apache reliably on
a system with grsec non executable stack, heap, and all addresses
randomized (and re-randomized after a crash). IIRC all code including
the executable was also position independent.

PIC and PIE have something in common with the "war on terror" some western
countries are playing these days ... lots of advantages in theory and 
lots of disadavtages in practice. (and thats putting it mildly)

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20080312/b6e01fc0/attachment.pgp>