Backend SEGFAULT on invalid PMT

[froedep@…]

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.

[Stuart Auchterlonie]

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.

[froedep@…]

Log file for latest SVN build

[froedep@…]

Backtrace file for latest SVN build

[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.

[danielk]

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.

[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.

[danielk]

Preliminary stab at this problem.

[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

[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

[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

[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.

[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.

[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.

[Janne <janne-mythtv@…>]

fix missing return

[Janne <janne-mythtv@…>]

fix HasCRC for PSIP

[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.

[Janne <janne-mythtv@…>]

added main ATSC tables to HasCRC()

[Janne <janne-mythtv@…>]

Added ATSC TableIDs to HasCRC

[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!

[Simon Kenyon]

end of log for BE

[danielk]

Updated version with more tables in HasCRC for ATSC

[danielk]

(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.

[Janne Grunau]

changeset 12480 backported to 0.20-fixes