[mythtv-users] backend segfault when re-entering livetv - fixes/0.28 with IPTV tuners

Fri Dec 2 12:08:45 UTC 2016

> -----Original Message-----
> From: mythtv-users [mailto:mythtv-users-bounces at mythtv.org] On Behalf
> Of Mark Perkins
> Sent: Wednesday, 30 November 2016 7:23 PM
> To: 'Discussion about MythTV' <mythtv-users at mythtv.org>
> Subject: Re: [mythtv-users] backend segfault when re-entering livetv -
> fixes/0.28 with IPTV tuners
> 
> 
> 
> > -----Original Message-----
> > From: mythtv-users [mailto:mythtv-users-bounces at mythtv.org] On Behalf
> > Of Mike Bibbings
> > Sent: Wednesday, 30 November 2016 1:22 AM
> > To: Discussion about MythTV <mythtv-users at mythtv.org>
> > Subject: Re: [mythtv-users] backend segfault when re-entering livetv -
> > fixes/0.28 with IPTV tuners
> >
> > On 29/11/16 14:04, Mark Perkins wrote:
> > > Hi all.
> > >
> > > I am building a new fixes/0.28 backend. I am testing using IPTV
tuners.
> > > However I am getting a backend segfault if I exit and then re-enter
> > > livetv.
> > > It doesn't seem to happen while channel surfing. It also doesn't
> > > seem to happen when I exit livetv (or enter the first time), but
> > > occurs as soon as I try to return to livetv.
> > >
> > > I even tried starting, going to livetv, exiting livetv, watching a
> > > recording, exiting recording, going back into livetv and still
> > > pulled a segfault as soon as I tried to get into livetv the second
time.
> > >
> > > I have run a gdb dump and have attached it here
> > > https://www.dropbox.com/s/ynmtlwpven2lkfs/gdb.txt?dl=0
> > >
> > > If anyone has any suggestions please let me know.
> > >
> > > Mythbackend version as follows:
> > > Please attach all output as a file in bug reports.
> > > MythTV Version : v0.28-97-ge9d0543
> > > MythTV Branch : fixes/0.28
> > > Network Protocol : 88
> > > Library API : 0.28.20161120-1
> > > QT Version : 5.6.1
> > > Options compiled in:
> > >   linux profile use_hidesyms using_alsa using_oss using_pulse
> > > using_pulseoutput using_backend using_bindings_perl
> > > using_bindings_python using_bindings_php using_dvb using_frontend
> > > using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv
> > > using_joystick_menu using_libcrypto using_libdns_sd using_libfftw3
> > > using_libxml2 using_lirc using_mheg using_opengl using_opengl_video
> > > using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus
> > > using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv
> > > using_profiletype using_systemd_notify using_bindings_perl
> > > using_bindings_python using_bindings_php using_freetype2
> > > using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads
> > > using_mheg using_libass using_libxml2
> > > _______________________________________________
> >
> > Which IPTV tuner(s) are you using ?
> >
> > I know of two mythtv trac tickets #12856 and #12773 (comment 10) -
> > both cause mythbackend seg faults in
> > recorders/httptsstreamhandler.cpp:217 in the circumstances you
> > describe when using VBOX IPTV tuners. At present you will need to
> > patch the source, see the trac tickets for details. If you
> are using
> > HLS Playlists that is going to be a problem as one of the patches
> > #12856 breaks those (temporary fix awaiting proper resolution).
> >
> > Mike
> >
> >
> > _______________________________________________
> Thanks Mike. I am using mumudvb to http unicast the dvb-t streams. I will
> check out the two trac tickets and report back what I find.
> _______________________________________________

Thanks Mike. I've had a bit of a look now and the symptoms you reported seem
to me to be near-identical to the symptoms that I am currently seeing.
However the patch made no difference for me. I initially thought that maybe
my use-case was falling into the HLS Playlist exception you mentioned but I
applied your logging patch and I was getting near-identical logging to you
so thought I would keep digging.

Just in case it is important - there are perhaps two slight differences
between my symptoms compared against the two tickets in trac. Firstly in the
notes against ticket 12856 (https://code.mythtv.org/trac/ticket/12856) it
notes that mythsingledownload is being triggered. I get that as well, but I
get it on the first entry into LiveTV (where I do not get a segfault) not
just the second entry into LiveTV. The other difference is that I seem to be
able to channel surf without crashes, I only crash on second LiveTV entry.

The other item to note is that I seem to be regularly (LiveTV) getting two
recordings for each program. The first zero bytes, the second seems to have
all the data. But they are always exactly 1 number apart, ie
1092_20161202080909.ts and 1092_20161202080910.ts. When MythTV does the
cleanup of LiveTV recordings I think it is only cleaning up the first one.

Anyway, long story short I ended up just incrementally applying more and
more logging to try and work out what was happening. Coding is not something
that I do but I eventually worked out that the main difference between my
first entry into LiveTV and my second entry into LiveTV is that at
https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders
/iptvchannel.cpp#L52 m_stream_data is still set on second LiveTV entry which
triggers SetStreamData(m_stream_data). I think after that it starts trying
to write the stream data to disk before the ringbuffer has finished getting
setup therefore crashes. I tried adding a line at the end of void
IPTVChannel::Close(void)
https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders
/iptvchannel.cpp#L86 to unset m_stream_data but couldn't work the semantics
out so just commented out lines 52 and 53 of iptvchannel.cpp so the check
never occurs.

So far that seems to have stopped the crashes, but I have only entered /
exited livetv a couple of times so will keep trying it over the next few
days and see if that breaks anything else.

The only other observation I made but ultimately it didn't fix anything so I
assume it is a dead end - but if I understand correctly the RingBufferReady
flag is already set on the second entry into LiveTV even before the
ringbuffer setup has occurred. I added something like:
    ClearFlags(kFlagRingBufferReady, __FILE__, __LINE__);
At line 3660 of tv_rec.cpp
(https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/tv_rec.c
pp#L3660) which got rid of the RingBufferReady flag at the second entry to
LiveTV - however it made no difference to anything. I guess I am including
it here both as a note to future-me and just in case it is significant to
someone who understands the code.