[MPlayer-dev-eng] mplayer -pie and libbluray

Alexander Roalter alex at roalter.it
Wed Aug 15 21:36:59 CEST 2012


On 08/15/2012 09:29 PM, Reimar Döffinger wrote:
> On Wed, Aug 15, 2012 at 08:54:45PM +0200, Alexander Roalter wrote:
>> On 08/15/2012 08:27 PM, Reimar Döffinger wrote:
>>>
>>> Yes, I tried playing a bluray, with both br:// and bd:// just to be sure.
>>> I can't know for sure it hit the code-path that caused your issue.
>>> Something like a backtrace of the crash and/or strdup and what the
>>> pointer value looks like or so might help.
>>> Maybe some kind of minimal reproduction case, like
>>> char *a(void){ return strdup("test") };
>>> compiled to a .so and a normal program compiled as PIE linking
>>> against it to see if that also triggers the issue?
>>> Or maybe figure out how address randomization is configured on your
>>> system? Maybe changing that will determine if there is a problem or not?
>>> However I can't really understand why it would work in valgrind,
>>> except that I'd guess it ends up not using address randomization.
>>
>> I can make a small test app and a test.so, and both do strdup. It
>> works even if I use PIE linking.
>>
>> But if I do add bd_open("/mnt/bd", NULL); and link against
>> libbluray, then also the test application segfaults (with PIE) or
>> works OK (without PIE).
>>
>> Running gdb on it... the bdpath=0xffffffff8201980 is an additional
>> printf I inserted to see the %p of the strdup'ed string.
>
> Let me guess: they forgot to include string.h where that strdup is,
> thus the return value is treated as int and sign-extended.
> It just happens to work if all addresses are < 32.

On one hand you're right:

libbluray/bluray.c:1008:13: warning: implicit declaration of function 
‘strdup’

But string.h is included, but only if one of the following is defined: 
__USE_SVID, __USE_BSD or __USE_XOPEN_EXTENDED



-- 
Cheers,
Alex


More information about the MPlayer-dev-eng mailing list