[MPlayer-users] Re: Mplayer crashes with wmv-files

[Stan Gammons]

Interesting. I could usually get mplayer to work each time IF I forced
it to use the proper video codec for the wmv file. Gmplayer dies no
matter what I try.

Do you think this is also the reason gmplayer just dies when after it
tries the second skin directory?



On Wed, 2004-02-11 at 18:48, Alex Eskin wrote:
>     This is not an athlon problem,  but a fedora problem.
> 
>    There is a bad interaction on Fedora between exec-shield, prelink,
>    and anything which uses windows dll's (i.e. wine, but also 
>    mplayer and xine). The immediate symptom I was seeing was a 
>    segmentation fault when trying to play windows media 9 files 
>    in mplayer.
> 
>    The cause of the problem is the following:
> 
>    The exec-shield patches in Fedora Core 1 also randomize the 
>    loading addresses of the system libraries. Because of prelink, 
>    this random assignment occurs during full-prelink time (which is 
>    normally every two weeks). Also, to help combat ASCII buffer 
>    overflow attacks, the libraries are packed as much as possible
>    into the first megabyte. 
> 
>    Now mplayer wants to load windows dll's at virtual address 
>    0x400000. If an important system library happens to be there, 
>    you get a segmentation fault. Whether or not it works literally
>    depends on the pahse of the moon :). 
> 
>    (This is not as much a problem as it used to be since mplayer
>     now plays most formats natively, but it is still annoying). 
> 
>    There is currently no workaround which is local to mplayer. 
>    The best one so far (which I found on codeweavers.com) is the
>    the following:
> 
>    
>    a) edit /etc/syconfig/prelink and change PRELINK_OPTS=-mR
>          to PRELINK_OPTS="-mR --no-exec-shield"
> 
>    b) touch /var/lib/misc/prelink.force
>    c) /etc/cron.daily/prelink 
> 
>   This relinks all the applications, and it takes
>   quite a while. The undocumented --no-exec-shield option
>   to /usr/sbin/prelink has the effect of randomizing
>   the library locations starting at 0x40000000 (so you
>   abandon the attempt to protect against ASCII overflows). 
> 
>   I hope a better solution will come along in the future. 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online.
> http://taxes.yahoo.com/filing.html
> 
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-users