Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#8740 closed defect (Fixed)

ILLEGAL INSTRUCTION crash in libmythsoundtouch library

Reported by: Stuart Auchterlonie Owned by: Janne Grunau
Priority: major Milestone: 0.24.1
Component: MythTV - Audio Output Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by Janne Grunau)

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.

Attachments (4)

illegal-instruction-gdb.txt (2.5 KB) - added by Stuart Auchterlonie 8 years ago.
GDB backtrace of the crash
t8740_remove_sse3_instructions.diff (1.7 KB) - added by Janne Grunau 8 years ago.
myth-ticket-8740.txt (2.2 KB) - added by J.Pilk@… 7 years ago.
Backtrace on selecting timestretch on P4 machine
test_cpuid.c (7.2 KB) - added by Janne Grunau 7 years ago.
compile with gcc -std=c99 -o test_cpuid test_cpuid.c

Download all attachments as: .zip

Change History (22)

Changed 8 years ago by Stuart Auchterlonie

Attachment: illegal-instruction-gdb.txt added

GDB backtrace of the crash

Changed 8 years ago by Janne Grunau

comment:1 Changed 8 years ago by Janne Grunau

Owner: changed from JYA to Janne Grunau
Priority: minormajor
Status: newaccepted

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.

comment:2 Changed 8 years ago by Janne Grunau

Resolution: fixed
Status: acceptedclosed

(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

comment:3 Changed 8 years ago by Stuart Auchterlonie

Resolution: fixed
Status: closednew

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

comment:4 Changed 8 years ago by robertm

Status: newassigned

comment:5 Changed 8 years ago by Janne Grunau

Description: modified (diff)

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.

comment:6 Changed 8 years ago by Janne Grunau

Owner: changed from Janne Grunau to jya

A backtrace would be handy

comment:7 Changed 8 years ago by robertm

Owner: changed from jya to JYA

comment:8 Changed 8 years ago by stuartm

Milestone: 0.240.24.1

comment:9 Changed 8 years ago by JYA

Owner: changed from JYA to Janne Grunau

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.

comment:10 in reply to:  6 Changed 8 years ago by Stuart Auchterlonie

Replying to janne:

A backtrace would be handy

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

Stuart

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by 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.

Changed 7 years ago by J.Pilk@…

Attachment: myth-ticket-8740.txt added

Backtrace on selecting timestretch on P4 machine

comment:13 Changed 7 years ago by J.Pilk@…

Backtrace from the P4 machine attached

comment:14 Changed 7 years ago by 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

Changed 7 years ago by Janne Grunau

Attachment: test_cpuid.c added

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

comment:15 Changed 7 years ago by 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

comment:16 Changed 7 years ago by robertm

Resolution: Fixed
Status: assignedclosed

Fixed in 49e8e9f5c

comment:17 Changed 7 years ago by Janne Grunau

fixed by aec0097 in fixes/0.24

comment:18 Changed 7 years ago by 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?

Note: See TracTickets for help on using tickets.