[mythtv] [mythtv-commits] Ticket #3720: Backend can recursively send messages to itself with a socket to connected to itself

[gad at jetcom.org]

Do any dev's have suggestions for the best solution to this problem?   
I'll gladly work out a patch & test for this.

Some questions that I presented in the ticket:
>  Some Questions:
>  Is it ok for the MBE to open a socket to himself to receive events on?
>  Is it ok for the MBE to redistribute BACKEND_MESSAGES to all of the
>  sockets connected? or should there be a recursion check in there?

Thanks.

Quoting MythTV <mythtv at cvs.mythtv.org>:

> #3720: Backend can recursively send messages to itself with a socket  
>  to connected
> to itself
> -----------------------+----------------------------------------------------
>  Reporter:  anonymous  |       Owner:  ijr
>      Type:  defect     |      Status:  new
>  Priority:  minor      |   Milestone:  unknown
> Component:  mythtv     |     Version:  head
>  Severity:  medium     |     Mlocked:  0
> -----------------------+----------------------------------------------------
>  I have been tracking down an issue that I have been seeing for a while now
>  where my master backend will get into a nice loop where it will
>  continually send BACKEND_MESSAGES to its self, and in doing so process
>  the message again, and repeat the process.  This tends to make the backend
>  not very responsive after that, and tho while it generally does not crash,
>  it does not respond to things in a timely manner.
>
>  This is a snippet from a log showing the symptom: (pruned a bit w/ some of
>  my debug)
---------- snipped logs (look at ticket) -----------------
>
>  I believe that the culprit to this problem is there are some cases where
>  ConnectToMasterServer can be called despite the fact that we *ARE* the
>  master server.
>  I see this in the log:
>
---------- snipped logs (look at ticket) -----------------
>  Once these extra sockets are created, it's only a matter of time before
>  things going awry.
>
>  I think this can be re-created in several different ways, however I did
>  find one sure fire one -- backtrace:
>
>  {{{
>  #0  MythContext::ConnectServer (this=0x6beab0, eventSock=0x2aaaac00e040,
>  hostname=@0x4800fc60, port=6543, blockingClient=false)
>      at mythcontext.cpp:880
>  #1  0x00002aaba6f1f97b in MythContext::ConnectToMasterServer
>  (this=0x6beab0, blockingClient=false) at mythcontext.cpp:867
>  #2  0x00002aaba6f1fa88 in MythContext::SendReceiveStringList
>  (this=0x6beab0, strlist=@0x4800fef0, quickTimeout=false, block=true)
>      at mythcontext.cpp:2451
>  #3  0x00002aaba5a316bf in RemoteCheckFile (pginfo=0x2aaaac10ea00,
>  checkSlaves=true) at remoteutil.cpp:117
>  #4  0x00002aaba599a18b in ProgramInfo::MarkAsInUse (this=0x2aaaac10ea00,
>  inuse=true, usedFor=@0x48010370) at programinfo.cpp:4019
>  #5  0x00002aaba5c65886 in NuppelVideoPlayer (this=0x2aaaac183720,
>  inUseID=@0x480106d0, info=0x2aaaac116640)
>      at NuppelVideoPlayer.cpp:269
>  #6  0x00002aaba5af8018 in PreviewGenerator::GetScreenGrab
>  (pginfo=0x2aaaac116640, filename=@0x2aaaac1166a0, secondsin=64,
>      bufferlen=@0x4801087c, video_width=@0x48010878,
>  video_height=@0x48010874, video_aspect=@0x48010870) at
>  previewgenerator.cpp:481
>  #7  0x000000000044b8e4 in MainServer::HandleGenPreviewPixmap
>  (this=0x2aaaac00af50, slist=@0x48010dd0, pbs=0x2aaaac0354d0)
>      at mainserver.cpp:3580
>  }}}
>
>  What I do here is using mythweb to retrieve the recording list, it needs
>  to generate a pixmap for a recording that was recorded on a slave backend.
>
>  I'd make a patch to fix something here, but I'm not sure appropriate fix,
>  and/or which aspect of this is a bug vs a feature.
>
>  Some Questions:
>  Is it ok for the MBE to open a socket to himself to receive events on?
>  Is it ok for the MBE to redistribute BACKEND_MESSAGES to all of the
>  sockets connected? or should there be a recursion check in there?
>
>  I've found this one case that will reproduce it, but I have a hunch there
>  there are more. (like the clearsettingscache on backend/main.cpp:487 seems
>  like it would also trigger it.) Obviously it might be better to prevent
>  the "bad stuff" from occuring, rather than trying to track down all of the
>  places that open sockets to the MBE.
>
>  If a dev wants to make a suggestion of how to proceed, then I'll gladly
>  patch/test this case. I finally took the time to track it down, but this
>  has been plaguing me for months.  I have also noticed another with this
>  problem: [http://www.gossamer-threads.com/lists/mythtv/users/270452]
>
>  My myth config if it matters:  Master BE/FE with 2 HD tuners and *all* the
>  storage. [diskless] slave BE/FE with pvr-150 recording to nfs storage on
>  master. MBO is on. Addtional frontends.
>
>  Any questions, feel free.
>
> --
> Ticket URL: <http://svn.mythtv.org/trac/ticket/3720>
> MythTV <http://svn.mythtv.org/trac>
> MythTV
> _______________________________________________
> mythtv-commits mailing list
> mythtv-commits at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits
>