[mythtv] Mutex destroy failure problem (was: Slave backend hangafter ANN command)

[Jason Gillis]

Isaac Richards wrote:
> Might check to see if the signal that's sent when the socket is closed
> (MainServer::endConnection) is getting called, and so the
> PlaybackSock object is getting prematurely deleted.

This looks like the likely culprit.

On my system, it looks like the following is happening:

.  SendReceiveStringList() calls ReadStringList()
.       When the slave disconnects, the socket gets closed
.       The thread calling ReadStringList() jumps over to endConnection().
.       endConnection() deletes the PlaybackSock object, causing the 
ReadStringList() call to return false
.  When ReadStringList() returns at this point, SendReceiveStringList() 
tries to access members of the now deleted PlaybackSock object which causes 
a seg fault

The problem, it seems, is that when the socket closes, the call to 
ReadStringList() doesn't return until after endConnection() finishes 
calling, so the PlaybackSock object is destroyed.  If there was some way for 
ReadStringList to return false at the same time that endConnection() 
executes, then this could work out, but it looks like it's all a single 
thread, so there's no chance for that to happen, and there doesn't seem to 
be an obvious way (to me) to hand control back to ReadStringList() so it can 
return false.

I modified endConnection to do the following:

void MainServer::endConnection(RefSocket *socket)
{
    vector<PlaybackSock *>::iterator it = playbackList.begin();
    for (; it != playbackList.end(); ++it)
    {
        QSocket *sock = (*it)->getSocket();
        if (sock == socket)
        {
            if (ismaster && (*it)->isSlaveBackend())
            {
                VERBOSE(VB_ALL, QString("Slave backend: %1 has left the "
                                        "building").arg((*it)->getHostname()));

                playbackList.erase(it);
                return;
            }
...


That allowed things to continue just fine after the slave disconnected. 
However, I don't doubt that this is "Not Good(tm)" from a many perspectives 
(leaks, etc) since none of the data is getting erased and removed from other 
structures.  It does show that the PlaybackSock is getting removed too soon.

So, is there any way to mark the PlaybackSock for destruction at a later 
time?

Jason