Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#8740 closed defect (Fixed)

ILLEGAL INSTRUCTION crash in libmythsoundtouch library

Reported by: stuarta Owned by: janne
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)

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 stuarta 4 years ago.
GDB backtrace of the crash
t8740_remove_sse3_instructions.diff (1.7 KB) - added by janne 4 years ago.
myth-ticket-8740.txt (2.2 KB) - added by J.Pilk@… 3 years ago.
Backtrace on selecting timestretch on P4 machine
test_cpuid.c (7.2 KB) - added by janne 3 years ago.
compile with gcc -std=c99 -o test_cpuid test_cpuid.c

Download all attachments as: .zip

Change History (22)

Changed 4 years ago by stuarta

GDB backtrace of the crash

Changed 4 years ago by janne

comment:1 Changed 4 years ago by janne

  • Owner changed from jyavenard to janne
  • Priority changed from minor to major
  • Status changed from new to accepted

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 4 years ago by janne

  • Resolution set to fixed
  • Status changed from accepted to closed

(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 4 years ago by stuarta

  • Resolution fixed deleted
  • Status changed from closed to new

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 4 years ago by robertm

  • Status changed from new to assigned

comment:5 Changed 4 years ago by janne

  • 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 follow-up: Changed 3 years ago by janne

  • Owner changed from janne to jya

A backtrace would be handy

comment:7 Changed 3 years ago by robertm

  • Owner changed from jya to jyavenard

comment:8 Changed 3 years ago by stuartm

  • Milestone changed from 0.24 to 0.24.1

comment:9 Changed 3 years ago by jyavenard

  • Owner changed from jyavenard to janne

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 3 years ago by stuarta

Replying to janne:

A backtrace would be handy

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

Stuart

comment:11 Changed 3 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 3 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 3 years ago by J.Pilk@…

Backtrace on selecting timestretch on P4 machine

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

Backtrace from the P4 machine attached

comment:14 Changed 3 years ago by janne

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 3 years ago by janne

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

comment:15 Changed 3 years ago by stuarta

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 3 years ago by robertm

  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixed in 49e8e9f5c

comment:17 Changed 3 years ago by janne

fixed by aec0097 in fixes/0.24

comment:18 Changed 3 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?

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.