ILLEGAL INSTRUCTION crash in libmythsoundtouch library

[Stuart Auchterlonie]

I have a recording which causes the frontend to die with an illegal instruction fault.

The backtrace is attached. As far as i can tell it's because this recording claims to have 2 audio tracks. ffmpeg output

Seems stream 0 codec frame rate differs from container frame rate: 50.00 (50/1) -> 25.00 (25/1) Input #0, mpegts, from '/myth/rec2/1029_20090924215900.mpg':

Duration: 01:06:56.87, start: 44126.278878, bitrate: 2467 kb/s Program 1

Stream #0.0[0x1f5]: Video: mpeg2video, yuv420p, 720x576 [PAR 64:45 DAR 16:9], 9000 kb/s, 25 tbr, 90k tbn, 50 tbc Stream #0.1[0x1f6](eng): Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s Stream #0.2[0x1f8](eng): Audio: mp3, 0 channels, s16 Stream #0.3[0x1f7](eng): Subtitle: dvbsub

I suspect the frontend is selecting the mp3 audio track which has 0 channels and is clearly bogus. I use timestretch on this recording by default, so it will be trying to adjust the audio to compensate.

I can make a sample available on request.

[Stuart Auchterlonie]

GDB backtrace of the crash

[Janne Grunau]

problem is caused by haddps/d instructions. They are only available in SSE3 and libsoundtouch just checks for SSE2. t8740_remove_sse3_instructions.diff should fix it.

[Janne Grunau]

(In [25585]) soundtouch: remove SSE3 instructions from TDStretchSSE2

HADDPS/D are SSE3 instructions. Replace them with SHUFPS/D and ADDPS/D and add the original versions as TDStretchSSE3.

Fixes #8740

[Stuart Auchterlonie]

The configure script is detecting SSE3 as available on this CPU leading to incorrect compilation of the SSE3 based routines rather than the SSE2 based routines.

Stuart

[Janne Grunau]

detecting SSE3 in configure is not the problem, that checks just if the assembler can assamble files with SSSE3 instructions. soundtouch actually checks the available extensions with cpuid und should call the right functions. I suspect there are more SSE3 instructions hidden in the SSE2 code.

[Janne Grunau]

A backtrace would be handy

[JYA]

I am not the author of that code, looking at the history, looks like Janne is..

The HD-audio change was just about using the existing code.

A simple work-around would be to enable SSE code only for SSE3 and forget about SSE2. Any x86 CPU > 7 years old would have SS3 support.

[Stuart Auchterlonie]

Replying to janne:

A backtrace would be handy

Suggest looking at the first attachment on the ticket....

Stuart

[J.Pilk@…]

I reported what seems to be the same problem in a Pentium 4 box under CentOS 5 running Myth 0.24-fixes from ATrpms: ​http://www.gossamer-threads.com/lists/mythtv/users/463911#463911

In the hope that this might be helpful I report here that the processor flags listed by KinfoCenter? (a KDE tool) for the affected machine include sse, sse2 and ss. For the F12 box, which is not affected, the 'Supported Instruction Sets' for the 6320 duo @ 1.86 GHz CPUs are listed as Intel MMX, Intel SSE and Intel SSE2.

[J.Pilk@…]

I now have a tunerless FE/BE running 0.24 under CentOS 5. CPU is a 1 GHz Celeron Coppermine - with 256 MB ram - and timestretch works; but it does stutter less at x0.8 than at x1.2. The only 'ss' related flag is sse.

[J.Pilk@…]

Backtrace on selecting timestretch on P4 machine

[J.Pilk@…]

Backtrace from the P4 machine attached

[Janne Grunau]

please download test_cpuid.c compile it with

gcc -o test_cpuid test_cpuid.c

run ./test_cpuid and report the output here. It should look like

mm_support1 = 0x0000001B
mm_support2 = 0x0000001B

[Janne Grunau]

compile with gcc -std=c99 -o test_cpuid test_cpuid.c

[Stuart Auchterlonie]

Intel(R) Pentium(R) 4 CPU 2.40GHz mm_support1 = 0x0000001B mm_support2 = 0x0000001B

AMD Athlon(tm) 64 Processor 3200+ mm_support1 = 0x0000003F mm_support2 = 0x0000003F

Stuart

[robertm]

Fixed in 49e8e9f5c

[Janne Grunau]

fixed by aec0097 in fixes/0.24

[J.Pilk@…]

I tried to compile test_cpuid.c on the core2duo box:

gcc -std=c99 -o test_cpuid test_cpuid.c

test_cpuid.c: Assembler messages: test_cpuid.c:56: Error: suffix or operands invalid for `pushf' test_cpuid.c:57: Error: suffix or operands invalid for `pop' test_cpuid.c:60: Error: suffix or operands invalid for `push' test_cpuid.c:61: Error: suffix or operands invalid for `popf' test_cpuid.c:62: Error: suffix or operands invalid for `pushf' test_cpuid.c:63: Error: suffix or operands invalid for `pop'

---

but it looks as if it isn't needed now?