mplayer ppc crash due to incorrect use of fsqrt

Bug #104630 reported by Benjamin Herrenschmidt
28
Affects Status Importance Assigned to Milestone
mplayer (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: mplayer

(this is not a dup of the various bugs about incorrect usage of altivec instructions on G3 machines...)

The mplayer package in feisty started crashing on G4 machines (among others) due to the use of
the fsqrt instruction which is part of the GP optional instruction set and currently only available,
afaik, on 64 bits processors.

It's been either open-coded or been generated by gcc due to the use of the -mpowerpc-gpopt compilation
flag, either way, it now SIGILL's on G4 machines which is fairly annoying.

Revision history for this message
Unai Uribarri (unaiur) wrote :

I want to confirm this bug. I've been testing with an old Mac Mini.

unai@vicky:~$ gdb -q gmplayer
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
MPlayer 2:1.0~rc1-0ubuntu9 (C) 2000-2006 MPlayer Team
AltiVec found
CPU: PowerPC
xscreensaver_disable: Could not find XScreenSaver window.
GNOME screensaver disabled
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 805610288 (LWP 13864)]
0x100cf4d8 in read_font_desc_ft ()
(gdb) where
#0 0x100cf4d8 in read_font_desc_ft ()
#1 0x100cfe84 in load_font_ft ()
#2 0x100e9778 in guiInit ()
#3 0x10061388 in main ()
(gdb) disassemble $pc $pc+4
Dump of assembler code from 0x100cf4d8 to 0x100cf4dc:
0x100cf4d8 <read_font_desc_ft+1336>: fsqrt f0,f0
End of assembler dump.

unai@vicky:~$ cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 1416.666661MHz
revision : 0.2 (pvr 8003 0102)
bogomips : 83.20
timebase : 41620997
platform : PowerMac
machine : PowerMac10,1
motherboard : PowerMac10,1 MacRISC3 Power Macintosh
detected as : 287 (Mac mini)
pmac flags : 00000010
L2 cache : 512K unified
pmac-generation : NewWorld

Revision history for this message
Unai Uribarri (unaiur) wrote :

I've recompiled this package from the sources (with dpkg-buildpackage) and realized that it was being built for a G5 CPU. Look at the the GCC flags -mcpu=7450 & -mtune=7450. Therefore, this package doesn't work on G3 nor G4 cpus.

cc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdeclaration-after-statement -O4 -mcpu=7450 -mtune=7450 -pipe -ffast-math -fomit-frame-pointer -maltivec -mabi=altivec -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include/directfb -I/usr/include -I/usr/include/ -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include -I/usr/include/dvdnav -I/usr/include/freetype2 -I/usr/include -I/usr/include/liveMedia -I/usr/include/UsageEnvironment -I/usr/include/BasicUsageEnvironment -I/usr/include/groupsock -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -c -o cavsdsp.o cavsdsp.c

Revision history for this message
Unai Uribarri (unaiur) wrote :

The mplayer package is compiled for a G5 cpu.

Changed in mplayer:
status: Unconfirmed → Confirmed
Revision history for this message
Unai Uribarri (unaiur) wrote :

Well. 7450 is indeed a G4 cpu. The problem seems to be that the configuration script detects the CPU of the machine and builds a binary tailored for that CPU.
The maintainer of this package should have a G5 machine; that's all.

Revision history for this message
Unai Uribarri (unaiur) wrote :

This is a duplicate of #85550, but I can't mark as so because #85550 is wrongly marked as a duplicate of #74282

Revision history for this message
Benjamin Herrenschmidt (benh-kernel) wrote : Re: [Bug 104630] Re: mplayer ppc crash due to incorrect use of fsqrt

On Sun, 2007-04-29 at 13:04 +0000, Unai Uribarri wrote:
> I've recompiled this package from the sources (with dpkg-buildpackage)
> and realized that it was being built for a G5 CPU. Look at the the GCC
> flags -mcpu=7450 & -mtune=7450. Therefore, this package doesn't work on
> G3 nor G4 cpus.

No, 7450 is G4. It will not work on G3 because of the use of altivec
though. There must be some other place causing generation of the
incorrect instruction, that can't be caused by mcpu-7450.

> cc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdeclaration-after-statement
> -O4 -mcpu=7450 -mtune=7450 -pipe -ffast-math -fomit-frame-pointer
> -maltivec -mabi=altivec -D_REENTRANT -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include/directfb
> -I/usr/include -I/usr/include/ -I/usr/include/SDL -D_GNU_SOURCE=1
> -D_REENTRANT -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include
> -I/usr/include/dvdnav -I/usr/include/freetype2 -I/usr/include
> -I/usr/include/liveMedia -I/usr/include/UsageEnvironment
> -I/usr/include/BasicUsageEnvironment
> -I/usr/include/groupsock -I/usr/include/gtk-2.0
> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/freetype2
> -I/usr/include/libpng12 -c -o cavsdsp.o cavsdsp.c
>

Revision history for this message
Benjamin Herrenschmidt (benh-kernel) wrote :

On Sun, 2007-04-29 at 13:26 +0000, Unai Uribarri wrote:
> Well. 7450 is indeed a G4 cpu. The problem seems to be that the configuration script detects the CPU of the machine and builds a binary tailored for that CPU.
> The maintainer of this package should have a G5 machine; that's all.

Heh, that's a serious gentooism :-)

Having altivec stuff in is fair enough. I don't know why the whole
package has to compile with altivec though, that makes it unsuitable for
G3s, it shouldn't be too hard to only build some files with -maltivec
and do runtime tests, but that's a different problem.

The configuration needs to be fixed.

Ben.

Revision history for this message
David Erosa (erosa) wrote :

The problem still exists in gutsy (as today):

...
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 805624608 (LWP 7801)]
0x100cd51c in read_font_desc_ft ()
(gdb) where
#0 0x100cd51c in read_font_desc_ft ()
#1 0x100cd904 in load_font_ft ()
#2 0x10092100 in vo_update_osd ()
#3 0x1009437c in vo_draw_text ()
#4 0x100a1420 in ?? ()
#5 0x10153d14 in ?? ()
#6 0x101141b8 in decode_video ()
#7 0x100628a8 in main ()
(gdb) disassemble $pc $pc+4
Dump of assembler code from 0x100cd51c to 0x100cd520:
0x100cd51c <read_font_desc_ft+2812>: fsqrt f0,f0
End of assembler dump.
(gdb)

I'll try to compile bzr and package source.

Revision history for this message
ski (skibrianski) wrote :

I too was having this problem.

I downloaded the source with apt-get source and twiddled with various CFLAGS and configure knobs, but really that was a waste of time, because i get a working mplayer binary with CFLAGS empty and no defaults on a G3. My guess is that this is a bug in the mplayer configuration system - they sternly warn you not to override CFLAGS (even if it's to provide a more compatible -mcpu= option!) If I add -mpowerpc-gpopt to CFLAGS, boom, the SIGILL's come back. Remove them again, and it builds fine. These CFLAGS, for example, work fine: "-mcpu=750 -Os -pipe -fno-strict-aliasing -mpowerpc-gfxopt"

I was very surprised to find that this resulted in a usable build of mplayer on this ol' G3 @ 400MHz. I can watch a 624x352 XviD without altivec. Only catches are that cpu usage is at 100% and there is the occasional dropped frame, and that the default audio out (oss) makes human voices scratchy and unlistenable. -ao alsa fixes that right up though.

In any event, here's how I did it for those of you playing along at home:

#NOTE: apt will pull in some prerequisites - keep track of these if you want to delete them later
sudo apt-get install libx264-dev libxvidcore4-dev libfaac-dev libasound2-dev libxv-dev libfontconfig1-dev
cd /tmp
sudo apt-get source mplayer
export CXXFLAGS="" ; export CFLAGS=""
./configure --enable-largefiles --disable-tv --disable-pvr --disable-tv-v4l1 --disable-tv-v4l2 \
--disable-tv-bsdbt848 --disable-unrarlib --disable-inet6 --disable-ftp
make && sudo make install

I also had a successful build with these CFLAGS, but haven't compared the two for performance or anything like that:
export CXXFLAGS="-mcpu=740 -Os -pipe -fno-strict-aliasing -mpowerpc-gfxopt" ;
export CFLAGS="-mcpu=740 -Os -pipe -fno-strict-aliasing -mpowerpc-gfxopt" ;

It takes between 20 minutes (with -Os) and 30 (with -O4 as mplayer's config script defaults to) to build the binary. You'll almost certainly want to add -maltivec if you are compiling on a G4.

I'm sure that even on my system there is more to tune, but I'm not running gentoo here, so I'm happy for the moment ;-)

Good luck!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.