mythfrontend crash in cc708decoder.cpp during playback

[Matthew Wood <mwood23@…>]

in playback, mythfrontend is crashing out apparently when parsing CC708 content (CEA-708(?))

I've attached a gdb.txt output as well as what 'nohup' outputs from starting mythfrontend from the command line. the mythfrontend.debug.log file has been abbreviated since it was approximately 1 million lines long. I edited out all of the content preceding where the start of the main playback loop.

mythtv@mythtv2:~$ mythfrontend  --version
Please attach all output as a file in bug reports.
MythTV Version   : v0.25pre-1796-gd3243cb
MythTV Branch    : master
Network Protocol : 65
Library API      : 0.25.20110414-3
QT Version       : 4.7.2
Options compiled in:
 linux debug use_hidesyms using_alsa using_backend using_bindings_php using_dvb using_frontend using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_mheg using_libxml2

compile was done with make distclean first, and /usr/local/mythtv (my install prefix) was completely wiped out before install.

my invocation from .xinitrc is: gdb mythfrontend -x gdbcommands

my gdbcommands file:

handle SIGPIPE nostop noprint
handle SIG33 nostop noprint
set logging on
set pagination off
set breakpoint pending on
break qFatal
set args -l mythdebug.log -v all
run
thread apply all bt full
set logging off

please let me know what I've missed or should do differently with this submission, it's only my second bug report to Trac :) thanks!

[Matthew Wood <mwood23@…>]

gdb output

[Matthew Wood <mwood23@…>]

output from 'nohup startx'

[Matthew Wood <mwood23@…>]

chunk of top of mythfrontend.debug.log file

[Matthew Wood <mwood23@…>]

~last 10 seconds until crash of mythfrontend.debug.log file

[Matthew Wood <mwood23@…>]

correction: mythfrontend debug file was too large, so I chopped off the top and the bottom and attached those separately.

[Matthew Wood <mwood23@…>]

Aha! while I was playing back this recording on my own (my daughter was playing it previously) I see that the stream from the broadcaster became increasingly blocky and choppy. We receive this show via OTA, on a non-amplified HD antenna. We get good signal strength for all the channels.

anyway, here's a tail of the mythfrontend output right as the crash happens:

2011-04-19 09:55:09.898 [ac3 @ 0x7fea860c6ea0]frame CRC mismatch
2011-04-19 09:55:09.898 [ac3 @ 0x7fea860c6ea0]frame sync error
2011-04-19 09:55:09.898 AFD Error: Unknown audio decoding error
2011-04-19 09:55:09.898 [ac3 @ 0x7fea860c6ea0]frame CRC mismatch
2011-04-19 09:55:09.900 Player(0): Video is 30 frames behind audio (too slow), dropping frame to catch up.
2011-04-19 09:55:09.900 Player(0): Video is 30 frames behind audio (too slow), dropping frame to catch up.
2011-04-19 09:55:09.900 [ac3 @ 0x7fea860c6ea0]frame sync error
2011-04-19 09:55:09.900 AFD Error: Unknown audio decoding error
2011-04-19 09:55:09.900 [ac3 @ 0x7fea860c6ea0]frame CRC mismatch
2011-04-19 09:55:09.900 Player(0): Video is 30 frames behind audio (too slow), dropping frame to catch up.
2011-04-19 09:55:09.901 AFD Error: VBI: Bad parity in EIA-608 data (bf81)
2011-04-19 09:55:09.901 Player(0): Video is 30 frames behind audio (too slow), dropping frame to catch up.
2011-04-19 09:55:09.902 Player(0): Video is 30 frames behind audio (too slow), dropping frame to catch up.
2011-04-19 09:55:09.902 Player(0): Waiting for video buffers...
mythfrontend: cc708decoder.cpp:268: void parse_cc_service_stream(CC708Reader*, uint): Assertion `((int)blk_size - i) >= 0' failed.

so the stream really deteriorates but I assume playback shouldn't crash mythfrontend. Perhaps exit to the menu with an error message (?)

[jpoet]

Probably same circumstance as described in #9716

[sphery]

Dup of #9716 (both triggering the assert at cc708decoder.cpp:268 ). Thanks for the report and the good debugging, Matthew (and for noticing the dup, John).

[Matthew Wood <mwood23@…>]

d'oh, sorry about the duplicate ticket! I had found #9582 in my search and thought maybe it was relevant due to the issue of parsing data it shouldn't be parsing; not to mention there was a patch created for that issue and I verified I had the updated code.

But I didn't see #9716! Thanks Michael and John for vetting this.