[mythtv] Ticket #2817: Unknown problem with socket communications causes segfault of backends

[Jim Westfall]

Mark Buechler <mark.buechler at gmail.com> wrote [01.09.07]:
> Ok, after looking at the code a bit more last night I had a thought about
> MainServer::customEvent() around the end where the iterator gets set back to
> the first entry in the list:
> 
>            if (sock->DownRef())
>            {
>                // was deleted elsewhere, so the iterator's invalid.
>                iter = playbackList.begin();
>            }
> 
> What exactly does this protect against? Is it possible for two threads to
> think each other has deleted entries in the list and reset their iterators
> when in fact neither one has? Can this be fixed with a mutex lock?

I dont think that if statement could ever be true.  It would mean that 
MythSocket was going to delete itself because there were no more refs to 
it.  In order for that to happen the PlaybackSock from which that 
MythSocket came from would also have had to been DownRef()'d where it was 
going to delete itself as well.  I dont think that is possible, since each 
PlaybackSock is UpRef()'d before being added to localPBSList.

The iter = playbackList.begin(); looks totally bogus to me since it 
would be changing iter to use playbackList, when the for() loop is setup 
using localPBSList.

If anything that code should look like

            if (reallysendit)
            {
                MythSocket *sock = pbs->getSocket();
                sock->UpRef();
                sock->Lock();
                sock->writeStringList(broadcast);
                sock->Unlock();
                sock->DownRef();
            }

jim


 
> 
> - Mark.
> 
> On 1/8/07, Mark Buechler <mark.buechler at gmail.com> wrote:
> >
> >I added some code around line 804 of mainserver.cpp to spit out the
> >QStringList entries as well as "broadcast" and the backend runs fine to a
> >point then send RECORDING_LIST_CHANGE hundreds of times a second for 
> >several
> >seconds and eventually starts sending SCHEDULE_CHANGE as well. Eventually
> >DONE_RECORDING starts getting sent as well as LIVETV_CHAIN. So, looks like
> >to me there's a queue which isn't getting cleared.
> >
> >- Mark.
> >
> >On 1/8/07, Martin M?ller <martin at martinm-76.dk> wrote:
> >>
> >> I have made a backtrace of mythbackend today as well. It seems to be the
> >> ProcessRequestWork bug that got me...
> >>
> >> I'll upload it to this ticket in the hope that it will enlighten someone
> >> :)
> >>
> >> I'm running revision 12434 at the moment...
> >>
> >> /Martin.
> >>
> >> ----- Mark Buechler <mark.buechler at gmail.com> wrote:
> >> > Has anyone had time to look at this? Looking at the bt's, there seems
> >> > to be two bugs, but by far the biggest is the one involving MythEvent
> >> > - specifically the QValueList extradata on sending in
> >> > MainServer::customEvent() and at times the receiving of QStringLists
> >> > in MainServer::ProcessRequestWork(). I've looked at the code for
> >> > obvious problems (like extradata not getting initialized before being
> >> > added to the "broadcast" QValueList), but nothing pops out at me. This
> >> > bug causes my two backends to crash once every day or two.
> >> >
> >> > - Mark.
> >> >
> >> >
> >> > On 12/25/06 , MythTV < mythtv at cvs.mythtv.org > wrote: #2817: Unknown
> >> > problem with socket communications causes segfault of backends
> >>
> >> _______________________________________________
> >> mythtv-dev mailing list
> >> mythtv-dev at mythtv.org
> >> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >>
> >
> >

> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev