mplayer crash with "illegal instruction" on PPC

[Marcello Semboli]

Binary package hint: mplayer

mplayer on xubuntu 6.10 crashes at startup on my iBook ppc G3.
It thrown "illegal instruction".
It crash with all video or audio files.
I think it is because it is cross-compiled.
I rebuild mplayer from source and it works.

[sam tygier (samtygier)]

works for me on ubuntu 6.10 on a G4.

can you get a backtrace

[Marcello Semboli (dinogen)]

Right.
I will attach a backtrace as soon as I can ;-)

[didier (did447-deactivatedaccount)]

Maybe a duplicate of #74282.

[Marcello Semboli (dinogen)]

This is the backtrace.
Yes, I think it is a duplicate bug as above.
Also VLC crashes same way.

[Tommy Trussell (tommy-trussell)]

I can confirm this bug on my PowerBook G3 "PDQ/Wallstreet II." From my reading it is probably a duplicate of bug 74282 -- same symptoms, and it affects G3 (non-Altivec) processors.

[Reinhard Tartler (siretart)]

marcello: without debug symbol, I'm afraid to say that backtrace is pretty worthless. mplayer is indeed using ffmpeg for nearly everything, so this is indeed bug #74282

[Daniel Gimpelevich (daniel-gimpelevich)]

When I tried the mplayer package from Edgy on a G3, I was very dismayed that my pleading to turn off Altivec in the Breezy ffmpeg package had not achieved any lasting effects. This time, it seems the mplayer packagers not only decided to naively trust the bogus upstream claims of runtime CPU detection on PPC, but through inaction due to insufficiently understanding the issues involved, added their own folly to the debian/rules file. It never got fixed in Edgy, and so far, not in Feisty, either. When using gcc to generate Altivec code that is executed conditionally upon the CPU present, that code MUST BE ISOLATED IN SEPARATE SOURCE FILES FROM ANY REFERENCE TO IT as a prerequisite for using Altivec when desired on a G4, while still supporting execution of equivalent code on a G3. The upstream mplayer developers can't seem to get this through their heads no matter how many bumps and bruises the VLC developers suffered on their way to achieving a reasonable facsimile of this claimed feature. The mplayer Altivec-handling code in the Feisty version (like the Edgy version before it, if not more so) is a horrid mess of properly isolated routines mixed in with stray code strewn around everywhere. In the hopes of getting upstream started on a true fix, I have applied clean-up hacks to it that allow for three modes of compilation:
1) Altivec disabled and runtime detection disabled
This would run G3 and G4 CPUs alike, without taking advantage of what a G4 has to offer beyond a G3. People who self-compile into /usr/local on a G3 would use this.
2) Altivec enabled and runtime detection disabled
This would run with maximum efficiency on a G4, and refuse to run at all on a G3. People who self-compile into /usr/local on a G4 would use this.
3) Altivec enabled and runtime detection enabled
This would run just fine on a G3, but would include Altivec code that would never be used. On a G4, Altivec code that is properly isolated would get used to increase efficiency and speed, but both generally Altivec-optimizable code and Altivec-specific code that was not properly isolated would be snubbed in favor of the same crap reserved for G3's. Ugly, but the mplayer developers have forced this hand to be played, by insisting everybody compile their own mplayer and not use any precompiled binary. This third variant is the one I make the package use.
Additionally, the stock package did not allow for the playing of mikmod, midi, or other such files, evidently because the upstream code for doing so was completely b0rked. I fix that here, too.
Please merge this patch into your bzr tree, and use your influence as mplayer packagers to get it merged upstream. Thank you. The diff was made against 2:1.0~rc1-0ubuntu3, IIRC.

[Benjamin Herrenschmidt (benh-kernel)]

Note that there seem to be -another- problem with mplayer on ppc. It dies on my G4 in feisty with an illegal instruction which is due to the use of the fsqrt instruction (specifically in read_font_desc_ft()). I haven't yet looked at wether this is a problem in the code picking wrong CPU optimisations or if it's been built -mpowerpc-gpopt, enabling use of hte optional GP instructions (which are really only available on 64 bits processors at this point).

[Benjamin Herrenschmidt (benh-kernel)]

Actually, since it's a different problem, I'll open a separate report

[Herbert V. Riedel (hvr)]

regarding the fsqrt issue see also bug #85550