Opened 13 years ago

Closed 12 years ago

#2664 closed defect (fixed)

Backend SEGFAULT on invalid PMT

Reported by: froedep@… Owned by: danielk
Priority: minor Milestone: 0.21
Component: dvb Version: head
Severity: low Keywords:
Cc: Stuart Auchterlonie Ticket locked: no

Description

When recording from a channel on multiplex A in the UK, such as five, five US, five Life, QVC, the backend will start recording without a problem, however, randomly crash with a segfault throughout almost every programme recorded.

This happens on both latest SVN as well as 0.20-fixes. I never had this problem with my current setup (two Compro DVB-T200 cards) on 0.19.

Other multiplexes record perfectly fine.

The first gdb log was taken with -v record,channel,siparser and failed in ProgramAssociationTable::toString. Guessing that this might be caused by the verbose logs, I changed the logging to -v none and ran gdb again. This time it failed in ProgramAssociationTable::ProgramPID.

The logs were generated using 0.20-fixes, however, latest svn creates the same error.

Attachments (12)

gdb.txt (17.9 KB) - added by anonymous 13 years ago.
gdb1.txt (15.8 KB) - added by anonymous 13 years ago.
myth.log (33.2 KB) - added by anonymous 13 years ago.
myth-svn.log (173.1 KB) - added by froedep@… 13 years ago.
Log file for latest SVN build
gdb-svn.txt (18.7 KB) - added by froedep@… 13 years ago.
Backtrace file for latest SVN build
2664-v1.patch (3.4 KB) - added by danielk 12 years ago.
Preliminary stab at this problem.
2664_v2.patch (3.6 KB) - added by Janne <janne-mythtv@…> 12 years ago.
fix missing return
2664_HasCRC_fix_v1.diff (3.9 KB) - added by Janne <janne-mythtv@…> 12 years ago.
fix HasCRC for PSIP
2664_HasCRC_fix_v2.diff (4.0 KB) - added by Janne <janne-mythtv@…> 12 years ago.
added main ATSC tables to HasCRC()
myth.2.log (5.0 KB) - added by Simon Kenyon 12 years ago.
end of log for BE
2664-v3.patch (10.5 KB) - added by danielk 12 years ago.
Updated version with more tables in HasCRC for ATSC
r12480_backported.diff (11.9 KB) - added by Janne Grunau 12 years ago.
changeset 12480 backported to 0.20-fixes

Download all attachments as: .zip

Change History (27)

Changed 13 years ago by anonymous

Attachment: gdb.txt added

Changed 13 years ago by anonymous

Attachment: gdb1.txt added

Changed 13 years ago by anonymous

Attachment: myth.log added

comment:1 Changed 13 years ago by Stuart Auchterlonie

Milestone: unknown0.21
Priority: majorminor

hmmm, nothing much obvious in that log apart from it looks like it's trying to process a broken packet.

In future please attach the backtraces from svn and we'll backport things if necessary to -fixes.

Also, i'm not having any trouble recording off that Mux, so it's partly your local conditions, and partly the handling of bad packets.

Changed 13 years ago by froedep@…

Attachment: myth-svn.log added

Log file for latest SVN build

Changed 13 years ago by froedep@…

Attachment: gdb-svn.txt added

Backtrace file for latest SVN build

comment:2 in reply to:  description Changed 13 years ago by froedep@…

I've added updated backtrace and log files for the latest SVN build. I've also modified ProgramAssociationTable::ProgramPID to add some extra logging. The method only adds the VERBOSE line as you can see below.

uint ProgramPID(uint i) const {

QString tmp1 = QString("Looking for PID: %1").arg(i);

VERBOSE(VB_RECORD, tmp1);

return (((psipdata()[(i<<2) + 2] & 0x1f) << 8) |

psipdata()[(i<<2) + 3]);

}

From the logs you can see that at the end this method is called in an infinite loop incrementing i until a segfault occurs.

Granted, the mux that five transmits on doesn't have the best signal in my area, but 0.19 never segfaulted in this way before. For reference, I'm receiving the signal from the Waltham transmitter and I've tried playing around with my aerial cabling and turning up/adding/removing signal boosters to see if any of it made a difference.

It would be nice if Myth could just drop these packets or whatever is causing it grief. I'd rather have a picture breakup than the backend crashing.

I've also upgraded my kernel since to try and eliminate that as the cause as well as upgrading the dvb drivers for my card. I will try a different DVB-T card this weekend to see if it makes any difference.

Thanks for looking into this issue. If you need any further information or perhaps a sample recording then contact me.

comment:3 Changed 13 years ago by danielk

Severity: mediumlow
Summary: Backend segfaults while recording from Mux A in the UKBackend SEGFAULT on invalid PMT
Version: 0.20head

This can only happen with broken hardware for which we have to disable CRC checking, so I'm lowering the severity to low. We should add some more sanity checking to the PAT & PMT parsers because we allow the CRC to fail, but it isn't a high priority because of the small number of cards which are effected.

comment:4 in reply to:  3 Changed 13 years ago by anonymous

Just a follow up to this, I tested an AVerMedia DVB-T 771 card in place of one of my Compro DVB-T200 cards over the weekend and have absolutely no segfault issues with this card. As soon as I set my T200 recording from Mux A, MythTV crashed as per usual. If I only let the 771 record Mux A everything was fine. Even with the combination of the 771 recording Mux A and the T200 recording anything but Mux A worked nicely.

I have made a swap on one of these cards so I will have the 771 in place and will look at replacing the T200 sometime soon.

Changed 12 years ago by danielk

Attachment: 2664-v1.patch added

Preliminary stab at this problem.

comment:5 in reply to:  3 ; Changed 12 years ago by martin@…

Replying to danielk:

This can only happen with broken hardware for which we have to disable CRC checking,

Hi,

Please could you explain what's broken about the hardware and why CRC checking is disabled. I have two of these cards and also experience this problem. I have hardware problems with the avermedia cards so I'm not keen to revert back.

I'll try and test the patch.

-- Thanks, M

comment:6 Changed 12 years ago by Simon Kenyon

not tried tweaking my dish yet - will do so tonight.

should PSIPTable::VerifyPSIP() not return a true at the end of the function?

tried the v1 patch and it still crashes. it seemed to munch the stack.

i wish this was considered a higher priority as my system is now unusable -- simon

comment:7 in reply to:  5 Changed 12 years ago by froedep@…

Sorry it took me so long to test your patch. I've applied it to the latest SVN, which builds fine. Problem is that no data is saved to the drive when I record anything. If I revert to SVN without the above patch I get the recordings as per usual.

This is the log I get when recording something - the programme appears in the recorded list as normal, just no data is saved.

2007-01-08 13:01:40.901 TVRec(1): StartRecording?(BBC News; Weather) 2007-01-08 13:01:40.901 TVRec(1): ClearFlags?(AskAllowRecording?,) -> RunMainLoop?, 2007-01-08 13:01:41.015 TVRec(1): StartedRecording?(0x82f8c98) fn(/mnt/store/video/mythtv/2001_20070108130200.mpg) 2007-01-08 13:01:41.017 TVRec(1): ClearFlags?(CancelNextRecording?,) -> RunMainLoop?, 2007-01-08 13:01:41.018 TVRec(1): Changing from None to RecordingOnly? 2007-01-08 13:01:41.018 TVRec(1): ClearFlags?(FrontendReady?,CancelNextRecording?,) -> RunMainLoop?, 2007-01-08 13:01:41.018 TVRec(1): SetFlags?(AskAllowRecording?,) -> RunMainLoop?,AskAllowRecording?, 2007-01-08 13:01:41.018 TVRec(1): Request: Program(yes) channel() input() flags(Recording,) 2007-01-08 13:01:41.022 TVRec(1): HW Tuner: 1->1 2007-01-08 13:01:41.022 TVRec(1): ClearFlags?(PENDINGACTIONS,) -> RunMainLoop?,AskAllowRecording?, 2007-01-08 13:01:41.023 TVRec(1): Starting Signal Monitor 2007-01-08 13:01:41.023 TVRec(1): SetupSignalMonitor?(1, 0) 2007-01-08 13:01:41.029 TVRec(1): Signal monitor successfully created 2007-01-08 13:01:41.029 TVRec(1): Setting up table monitoring. 2007-01-08 13:01:41.039 Using profile 'Live TV' to record 2007-01-08 13:01:41.039 TVRec(1): DVB service_id 4166 on net_id 9018 tsid 4102 2007-01-08 13:01:41.039 TVRec(1): Successfully set up DVB table monitoring. 2007-01-08 13:01:41.048 TVRec(1): SetFlags?(SignalMonitorRunning?,) -> RunMainLoop?,AskAllowRecording?,SignalMonitorRunning?, 2007-01-08 13:01:41.048 TVRec(1): ClearFlags?(WaitingForSignal?,) -> RunMainLoop?,AskAllowRecording?,SignalMonitorRunning?, 2007-01-08 13:01:41.049 TVRec(1): SetFlags?(WaitingForSignal?,) -> RunMainLoop?,AskAllowRecording?,WaitingForSignal?,SignalMonitorRunning?, 2007-01-08 13:01:41.049 TVRec(1): ClearFlags?(NeedToStartRecorder?,) -> RunMainLoop?,AskAllowRecording?,WaitingForSignal?,SignalMonitorRunning?, 2007-01-08 13:01:41.049 TVRec(1): SetFlags?(NeedToStartRecorder?,) -> RunMainLoop?,AskAllowRecording?,WaitingForSignal?,NeedToStartRecorder?,SignalMonitorRunning?, 2007-01-08 13:01:41.172 CreatePATSingleProgram() 2007-01-08 13:01:41.173 PAT in input stream 2007-01-08 13:01:41.173 Program Association Table

PSIP tableID(0x0) length(37) extension(0x1006)

version(25) current(1) section(0) last_section(0)

tsid: 4102

programCount: 7

program number 0 has PID 0x 10 data 0x 0 0x 0 0xe0 0x10 program number 4166 has PID 0x1046 data 0x10 0x46 0xf0 0x46 program number 4351 has PID 0x10ff data 0x10 0xff 0xf0 0xff program number 4415 has PID 0x113f data 0x11 0x3f 0xf1 0x3f program number 4479 has PID 0x117f data 0x11 0x7f 0xf1 0x7f program number 4671 has PID 0x123f data 0x12 0x3f 0xf2 0x3f program number 4230 has PID 0x1086 data 0x10 0x86 0xf0 0x86

2007-01-08 13:01:41.174 desired_program(4166) pid(0x1046) 2007-01-08 13:01:41.174 pmt_pid(0x1046) 2007-01-08 13:01:41.174 PAT for output stream 2007-01-08 13:01:41.174 Program Association Table

PSIP tableID(0x0) length(13) extension(0x1006)

version(25) current(1) section(0) last_section(0)

tsid: 4102

programCount: 1

program number 1 has PID 0x1046 data 0x 0 0x 1 0xf0 0x46

comment:8 in reply to:  6 Changed 12 years ago by Janne <janne-mythtv@…>

Replying to Simon Kenyon:

should PSIPTable::VerifyPSIP() not return a true at the end of the function?

yes, gcc should have issued a warning á la "control reaches end of non-void function". Sorry, I forgot to report it after I compiled with the patch.

i wish this was considered a higher priority as my system is now unusable

The code hasn't changed much in the last time. You should be able to make your system useable again if you fix your recption.

comment:9 Changed 12 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

comment:10 Changed 12 years ago by Simon Kenyon

gcc does issue a warning.

i was reviewing the errors (none) and the warnings (lots) to make sure everything compiled correctly. that is when i noticed the problem. i made an assumption that if it fell through all the conditions, then the return result should be true.

comment:11 Changed 12 years ago by Stuart Auchterlonie

With this patch, test recordings fail with the following in mythbackend log

PSIPTable: Failed CRC check 0x0 != 0x5b168510 for StreamID = 0x0

which would cause the PAT & PMT tables not to be found by the signalmonitor.

Changed 12 years ago by Janne <janne-mythtv@…>

Attachment: 2664_v2.patch added

fix missing return

Changed 12 years ago by Janne <janne-mythtv@…>

Attachment: 2664_HasCRC_fix_v1.diff added

fix HasCRC for PSIP

comment:12 Changed 12 years ago by Janne <janne-mythtv@…>

PESPacket::HasCRC() doesn't work for PSI tables, since they have an entirely different header. 2664_HasCRC_fix_v1.diff decides wheter the table has a CRC or not based on the TableID. At least for the DVB and MPEG tables it works. I haven't yet searched for the ATSC standard so it returns false for the ATSC tables.

Changed 12 years ago by Janne <janne-mythtv@…>

Attachment: 2664_HasCRC_fix_v2.diff added

added main ATSC tables to HasCRC()

comment:13 Changed 12 years ago by Janne <janne-mythtv@…>

Added ATSC TableIDs to HasCRC

comment:14 Changed 12 years ago by Simon Kenyon

BE just crashed this morning. glibc fell over.

i've attached the end of the log.

regards -- simon PS is did last 12 hours though!

Changed 12 years ago by Simon Kenyon

Attachment: myth.2.log added

end of log for BE

Changed 12 years ago by danielk

Attachment: 2664-v3.patch added

Updated version with more tables in HasCRC for ATSC

comment:15 Changed 12 years ago by danielk

Resolution: fixed
Status: newclosed

(In [12480]) Fixes #2664. Fixes SEGFAULT on invalid PAT/PMT.

There were three problems with how we handled table validation:

  • If the DVB card mangled CRCs we didn't perform any validation
  • We performed the validation after the redundancy check, if

the signal is very noisy we can get in trouble just doing this.

  • We didn't always check the CRC when we should have because the

HasCRC() function relied on the PES packet structure and the PSIP tables depart somewhat from the basic PES packet structure.

These problems have been fixed in this commit along with a bug in the section tracking that was evident in a backtrace of a broken packet processing gone awry.

The code was by myself & Janne, but all the bugs would not have been found without the assistance of froedep at googlemail and Simon Kenyon.

HasCRC() does alias some table ids that are shared amoung the various standards that sit on top of MPEG, but AFAIK the aliased tables do all seem to agree on whether the table should have a CRC.

Changed 12 years ago by Janne Grunau

Attachment: r12480_backported.diff added

changeset 12480 backported to 0.20-fixes

Note: See TracTickets for help on using tickets.