Opened 14 years ago

Closed 14 years ago

#8235 closed defect (invalid)

segfault when channel changed in LiveTV

Reported by: warpme@… Owned by: Isaac Richards
Priority: critical Milestone: unknown
Component: MythTV - General Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

Changing channel durring liveTV my BE generates following entry in log:

2010-03-27 17:25:19.782 Preview Error: Preview process not ok. fileinfo(/myth/tv/5008_20100327172503.mpg.png) exists: 0 readable: 0 size: 0 2010-03-27 17:25:19.785 Preview Error: Despite command '/usr/bin/mythbackend --generate-preview 0x0 --chanid 5008 --starttime 20100327172503 ' returning success

Immiedetelly after this mythbackend generates following segfault: mythtv kernel: mythbackend[9169]: segfault at 6f6e6c6d ip b72bf90e sp bfabd410 error 6 in libmythtv-0.23.so.0.23.0[b6d35000+9f5000]

It is on 0.23-rc1 23786

Attachments (1)

gdb.txt (23.3 KB) - added by warpme@… 14 years ago.
gdb trace file

Download all attachments as: .zip

Change History (7)

comment:1 Changed 14 years ago by robertm

Milestone: 0.23unknown
Status: newinfoneeded_new

We need a real backtrace.

http://www.mythtv.org/wiki/Debugging

Changed 14 years ago by warpme@…

Attachment: gdb.txt added

gdb trace file

comment:2 Changed 14 years ago by warpme@…

Hi devs,

As it is production system I want to have minimal downtimes. Here is gdb.txt from non-debug build. If debug build is required - I can do so, but first I'm trying with non-debug as I want to avoid recompie-reinstall on production backend.

segfault: Mar 28 21:45:05 mythtv kernel: mythbackend[14531]: segfault at a5a5a6a8 ip b7b3290e sp bfffdd00 error 6 in libmythtv-0.23.so.0.23.0[b75a8000+9f5000]

gdb.txt attached

comment:3 Changed 14 years ago by robertm

Yes, a backtrace with debug symbols will be needed.

comment:4 Changed 14 years ago by robertm

Resolution: invalid
Status: infoneeded_newclosed

No response. Original backtrace was a SIGINT, not a segfault. If this occurs with .23-RC3 or .23-fixes, this ticket can be re-opened with a backtrace that shows an actual segfault.

comment:5 in reply to:  4 Changed 14 years ago by warpme@…

Resolution: invalid
Status: closednew

Replying to robertm:

No response. Original backtrace was a SIGINT, not a segfault. If this occurs with .23-RC3 or .23-fixes, this ticket can be re-opened with a backtrace that shows an actual segfault.

Robert,

Sorry for long silence (I was blocked by other things). This seq fault issue is quite specific:

-it is only present on my DVB-T channels (I have also: analog and DVB-S/DVB-S2). My DVB-T is H.264 based.

-segfault pops after channel change - when decoder is adapting to new stream. Sequence is more-less following:

1.current channel plays

2.user changing channel

3.picture on current channel stops moving

4.picture from new channel appears (it is still)

5.2-3 sec latter segfault appears

6.immediately after p.5 picture starts to move

-segfault appears only when I change from DVB-T channel to DVB-T channel. Changing from/to other channels to DVB-T is not producing segfault.

7.attached by me gdb traces were with this segfault - despite they didn't include any infos about segfault. Will compilation/tracing with -debug option help then here ?

I'm on 0.23-fixes 24609

br

comment:6 Changed 14 years ago by robertm

Resolution: invalid
Status: newclosed

You are not experiencing a playback segfault, it's just preview generation that is failing on you. As requested above, please only reopen this when you have a backtrace for the segfault in question. If you need help with how to create a backtrace, please ask on the users list. We also need you to make sure you have a clean build environment by removing the old libraries. You need to run the preview generation command on your backend from within gdb, not send in backtraces of your frontend while the BE fails.

Note: See TracTickets for help on using tickets.