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

[Måns Rullgård]

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> On Sun, 2008-03-09 at 19:30 +0000, M?ns Rullg?rd wrote:
>> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>> 
>> > On Sun, 2008-03-09 at 18:35 +0000, M?ns Rullg?rd wrote:
>> >> Why can't the code that takes the address of a function get it from
>> >> the GOT instead of returning the address of the PLT entry?  The only
>> >> requirement for this to work would be forcing any functions whose
>> >> addresses are taken to be resolved at load time.  There is no need for
>> >> modifying code areas at runtime at all.
>> >
>> > That IS what happens in PIC code. The issue that started this thread
>> > happened because there was non-PIC code using the address in the
>> > process. I already explained in reply to your earlier mail that the code
>> > generated for ffmpeg.c ("movq   $0x4038a0,0x48(%rsp)") writes a direct
>> > value that is included in the assembler instruction itself. You need to
>> > use -fPIC if you want the compiler to generate extra indirection through
>> > the GOT.
>> 
>> So you're basically saying that calling PIC code from non-PIC code
>> doesn't work reliably, and that you're fine with that?
>
> No. Everything works reliably as long as you don't use -Bsymbolic. Even
> if you do use -Bsymbolic calling still works reliably. What -Bsymbolic
> makes unreliable is the addresses of objects defined in the library. For
> functions code inside the library will see the address of the main
> function while code outside the library may see an address in the PLT.
> For other variables code inside the library will see the address of the
> original variable whereas code outside may see a copy relocation. The
> addresses outside can be the same if there is no non-PIC code that
> references the symbol.
>
> So basically IF you use -Bsymbolic AND do not compile the main program
> with -fPIC then you can only rely on symbols defined in the library to
> refer to similarly behaving objects inside and outside, not necessarily
> to refer to the same object at the same address.

I know how it works, and I am not at all happy with it.  It is in
blatant violation of the C standard, without so much as a hint about
this in the manual.

-- 
M?ns Rullg?rd
mans at mansr.com