Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#11318 closed Bug Report - Crash (fixed)

Segfault in mythbackend (mainserver/autoexpire?)

Reported by: verycoldpenguin@… Owned by: stuartm
Priority: blocker Milestone: 0.27
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I am experiencing a segfault in mythbackend, compiled on Centos 6.3 from master, using QT 4.8.4 (also present on QT 4.8.3). The setup is non-standard, but I believe that this is a generic issue (possibly being hit by the fact the system is an edge case). Symptoms are a segfault, when the system is relatively idle. I originally thought that it was triggered shortly after a recording finished, but, after furthther testing this has not been the case. I have not yet been able to trigger the fault at will. It is generally repeatable, usually between 1-6 hours, I don't think that it has been over 48 hours to trigger since I started looking for it. Here is a snippet of code from mainserver.cpp which I believe is the fault. To me, it would seem that the incrementation of 'it' in the section is not needed, and could be the cause. But, I don't see why this isn't hitting more people if it is. This is starting at line 4667:


void MainServer::GetFilesystemInfos(QList<FileSystemInfo> &fsInfos)
{
    QStringList strlist;
    FileSystemInfo fsInfo;

    fsInfos.clear();

    BackendQueryDiskSpace(strlist, false, true);

    QStringList::const_iterator it = strlist.begin();
    while (it != strlist.end())
    {
        fsInfo.setHostname(*(it++));
        fsInfo.setPath(*(it++));
        fsInfo.setLocal((*(it++)).toInt() > 0);
        fsInfo.setFSysID(-1);
        ++it;
        fsInfo.setGroupID((*(it++)).toInt());
        fsInfo.setBlockSize((*(it++)).toInt());
        fsInfo.setTotalSpace((*(it++)).toLongLong());
        fsInfo.setUsedSpace((*(it++)).toLongLong());
        fsInfo.setWeight(0);
        fsInfos.push_back(fsInfo);
    }

Snippet from backtrace (full crash attached). Sorry but the line number changed (it is the one immediately after the '++it;') in the current head.


Thread 19 (Thread 0x7fffcebfd700 (LWP 15361)):
#0  0x00007fffef24ae74 in QLocalePrivate::stringToLongLong(QString const&, int, bool*, QLocalePrivate::GroupSeparatorMode) const () from /usr/local/Trolltech/Qt-4.8.4/lib/libQtCore.so.4
No symbol table info available.
#1  0x00007fffef27219c in QString::toLongLong(bool*, int) const () from /usr/local/Trolltech/Qt-4.8.4/lib/libQtCore.so.4
No symbol table info available.
#2  0x00007fffef272239 in QString::toInt(bool*, int) const () from /usr/local/Trolltech/Qt-4.8.4/lib/libQtCore.so.4
No symbol table info available.
#3  0x00000000004948f5 in MainServer::GetFilesystemInfos (this=0x89f140, fsInfos=...) at mainserver.cpp:4662
        strlist = {<QList<QString>> = {{p = {static shared_null = {ref = {_q_value = 604}, alloc = 0, begin = 0, end = 0, sharable = 1, array = {0x0}}, d = 0x7fffa4050520}, d = 0x7fffa4050520}}, <No data fields>}
        __FUNCTION__ = "GetFilesystemInfos"
        fsInfo = {<QObject> = {<No data fields>},

Both my begin and end are 0, I think that the while line should possibly be changed from: while (it != strlist.end()) to: while (it < strlist.end()) And possibly the 'it++;' removed. I don't think that the code should have been run anyway though (given that begin and end should both return 0, or the same pointer).

Attachments (4)

myth.output (43.4 KB) - added by verycoldpenguin@… 7 years ago.
Crash trace
myth.version (598 bytes) - added by verycoldpenguin@… 7 years ago.
Myth version info
patch.txt (2.6 KB) - added by verycoldpenguin@… 7 years ago.
Patch 1 - Appears to fix indexing issue with BackendQueryDiskSpace? and GetFileSystemInfos?
patch2 (9.6 KB) - added by verycoldpenguin@… 7 years ago.
Patch2 - Ugly patch to mask the effects of truncated data being returned from slave backends

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by verycoldpenguin@…

Attachment: myth.output added

Crash trace

Changed 7 years ago by verycoldpenguin@…

Attachment: myth.version added

Myth version info

comment:1 Changed 7 years ago by stuartm

Milestone: unknown0.26.1
Owner: set to stuartm
Status: newaccepted

comment:2 Changed 7 years ago by verycoldpenguin@…

By applying the following patch, which is as far as I know more syntactically correct, then the particular segfault doesn't occur.

diff --git a/mythtv/programs/mythbackend/mainserver.cpp b/mythtv/programs/mythbackend/mainserver.cpp
index f38ba4a..fa13dc8 100644
--- a/mythtv/programs/mythbackend/mainserver.cpp
+++ b/mythtv/programs/mythbackend/mainserver.cpp
@@ -4673,20 +4673,21 @@ void MainServer::GetFilesystemInfos(QList<FileSystemInfo> &fsInfos)

     BackendQueryDiskSpace(strlist, false, true);

-    QStringList::const_iterator it = strlist.begin();
-    while (it != strlist.end())
+    QStringList::const_iterator it = strlist.constBegin();
+
+    while (it != strlist.constEnd())
     {
-        fsInfo.setHostname(*(it++));
-        fsInfo.setPath(*(it++));
-        fsInfo.setLocal((*(it++)).toInt() > 0);
+        fsInfo.setHostname(*(it));
+        fsInfo.setPath(*(it));
+        fsInfo.setLocal((*(it)).toInt() > 0);
         fsInfo.setFSysID(-1);
-        ++it;
-        fsInfo.setGroupID((*(it++)).toInt());
-        fsInfo.setBlockSize((*(it++)).toInt());
-        fsInfo.setTotalSpace((*(it++)).toLongLong());
-        fsInfo.setUsedSpace((*(it++)).toLongLong());
+        fsInfo.setGroupID((*(it)).toInt());
+        fsInfo.setBlockSize((*(it)).toInt());
+        fsInfo.setTotalSpace((*(it)).toLongLong());
+        fsInfo.setUsedSpace((*(it)).toLongLong());
         fsInfo.setWeight(0);
         fsInfos.push_back(fsInfo);
+        ++it;
     }

     LOG(VB_SCHEDULE | VB_FILE, LOG_DEBUG, "Determining unique filesystems");

However, a similar segfault now occurs at 4589 (void MainServer::BackendQueryDiskSpace?()):

...
    QStringList::const_iterator it = strlist.begin();
    while (it != strlist.end())
    {
        fsInfo.setHostname(*(it++));
        fsInfo.setPath(*(it++));
        fsInfo.setLocal((*(it++)).toInt() > 0);
        fsInfo.setFSysID(-1);
        ++it;   // Without this, the strlist gets out of whack
 4589:       fsInfo.setGroupID((*(it++)).toInt());
        fsInfo.setBlockSize((*(it++)).toInt());
        fsInfo.setTotalSpace((*(it++)).toLongLong());
        fsInfo.setUsedSpace((*(it++)).toLongLong());
        fsInfos.push_back(fsInfo);
    }
    strlist.clear();

I don't know git very well, is there any way of finding out who added the comment at 4588: ++it;? It seems to me a line asking for trouble, but intentionally added.

comment:3 Changed 7 years ago by gregorio.gervasio@…

I think this may be related to ticket #11316. I ran into the exact same segfault while debugging that one. I think what is happening is that when the master issues a QUERY_FREE_SPACE to a slave backend, it may receive an unexpected BACKEND_MESSAGE event before the actual response. Since the event message does not match the string list format expected by the parsing code shown above, it can cause a segfault.

Here is an example in one of my logs (-v socket,network --loglevel debug):

2012-12-28 20:00:00.104533 I [25772/25852] MythSocketThread(91) mythsocket.cpp:697 (WriteStringListReal) - MythSocket(b247f0:91): write -> 91 16      QUERY_FREE_SPACE
2012-12-28 20:00:00.327473 I [25772/25852] MythSocketThread(91) mythsocket.cpp:898 (ReadStringListReal) - MythSocket(b247f0:91): read  <- 91 105     BACKEND_MESSAGE[]:[]UPDATE_RECORDING_STATUS 5 2703 2012-12-29T03:30:00Z -3 2012-12-29T04:00:00Z[]:[]empty
2012-12-28 20:00:00.327543 D [25772/25852] MythSocketThread(91) mythsocket.cpp:284 (CallReadyReadHandler) - MythSocket(b247f0:91): calling m_callback->readyRead()
2012-12-28 20:00:00.329233 D [25772/25852] MythSocketThread(91) mythsocket.cpp:284 (CallReadyReadHandler) - MythSocket(b247f0:91): calling m_callback->readyRead()
2012-12-28 20:00:00.333592 E [25772/25808] Scheduler mythsocket.cpp:351 (SendReceiveStringList) - MythSocket(b247f0:91): Got MythEvent on non-event socket

The actual response arrives later and is treated as a response to a different query:

2012-12-28 20:00:00.337598 I [25772/25852] MythSocketThread(91) mythsocket.cpp:697 (WriteStringListReal) - MythSocket(b247f0:91): write -> 91 40      QUERY_REMOTEENCODER 13[]:[]IS_BUSY[]:[]5
2012-12-28 20:00:00.337651 I [25772/25852] MythSocketThread(91) mythsocket.cpp:898 (ReadStringListReal) - MythSocket(b247f0:91): read  <- 91 295     slave1.home[]:[]/home/mythtv/store.w0[]:[]1[]:[]-1[]:[]10[]:[]4096[]:[]1412510704[]:[]1342588920[]:[]slave1.home[]:[]/home/mythtv/store.w1[]:[]1[]:[]-1[]:[]17[]:[]4096[]:[]488327328[]:[]412500328[]:[]slave1.home[]:[]/home/mythtv/store.w2[]:[]1[]:[]-1[]:[]34[]:[]4096[]:[]1952559696[]:[]572217596

comment:4 Changed 7 years ago by verycoldpenguin@…

I am not sure that this is related to 11316. Since last night and this afternoon, the protocol version was incremented (without me realising). I was able to reproduce the bug with the master running a newer protocol than the slave. This should have meant that the slave was not having messages accepted by the master I believe, and thus the messages you are seeing would not have been accepted by the master in order to produce the problem. I attach a patch which appears to work for me.

Changed 7 years ago by verycoldpenguin@…

Attachment: patch.txt added

Patch 1 - Appears to fix indexing issue with BackendQueryDiskSpace? and GetFileSystemInfos?

comment:5 Changed 7 years ago by verycoldpenguin@…

Please do not use patch.txt (Patch 1). Although it neatly stops the segfault, it completely renders useless the two pieces of code :)

Hello Gregorio, I am sorry, it looks like you might be right. I made the assumption that if the protocol versions were different, then the master and slave backends would not communicate. However, it appears that although the slave may not connect to the master if the version is different, the master can connect to the slave. Perhaps this should be listed as a separate bug, or perhaps it is intentional, either way it is a pain in this instance.

I have attached a patch2. This is an ugly patch, it has many debug/log prints and areas commented out. With this, it can be seen that the system correctly determines information from the local database. It also shows that often it does manage to communicate with the remote backend (although again whilst this was running, there was a protocol mis-match, 76 slave ->77 master). A lot of the time the correct information was returned (the number of lines being a multiple of 8). However, often, the number of lines being returned (after the local determination) is not a multiple of 8. This would suggest that the information returned was truncated. In these instances, the patch2 supplied will ignore data that doesn't divide by 8. This masks the symptoms of the problems, meaning that the segfault will not occur. However, investigation should be made as to how to fix these truncations.

I will apply the patch from 11316 and see whether I see any more instances of 11318. I think however that a refined version of patch2 would be worthwhile incorporating anyway, in case communication problems occur from elsewhere in the future.

Changed 7 years ago by verycoldpenguin@…

Attachment: patch2 added

Patch2 - Ugly patch to mask the effects of truncated data being returned from slave backends

comment:6 Changed 7 years ago by verycoldpenguin@…

Here is output (with patch2 incorporated). The information displayed is the number of lines entered into the strlist array, which is used to determine the filesystem info. The filesystem info is ordered information (directory, hostname, etc. etc.) one item per line. This means that 8 lines should complete 1 record. For my system, the correct response for a running slave backend should be 48 items. 32 items occur if the backend was not contactable. The 81 demonstrates 11316 I believe.

[root@mythbackend mythtv]# grep CP ~/myth.output11 |grep Receiv |grep -v 32 |grep -v 48 |grep -v 40
2013-01-02 23:54:00.081976 I  CP2 Received 81
2013-01-02 23:54:00.659425 I  CP2 Received 33
2013-01-02 23:54:00.712997 I  CP2 Received 33
2013-01-02 23:56:14.811641 I  CP2 Received 33
2013-01-03 00:12:14.862054 I  CP2 Received 33
2013-01-03 00:27:14.924176 I  CP2 Received 33
2013-01-03 00:42:14.978151 I  CP2 Received 33
2013-01-03 06:25:18.865077 I  CP2 Received 35
2013-01-03 06:25:18.906438 I  CP2 Received 33
2013-01-03 06:46:59.630590 I  CP2 Received 35
2013-01-03 06:56:27.575800 I  CP2 Received 35
2013-01-03 06:56:27.630194 I  CP2 Received 33
2013-01-03 07:11:27.677304 I  CP2 Received 33

2013-01-02 23:54:00.076160 I  AutoExpire: Cardid 2: is starting a recording on an unknown fsID soon.
2013-01-02 23:54:00.076167 I  AutoExpire: CalcParams()
2013-01-02 23:54:00.077625 I  Processing request for sock 79
2013-01-02 23:54:00.077725 I  MythSocket(8be090:79): read  <- 79 82      BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE ADD 13992 2013-01-02T23...
2013-01-02 23:54:00.077755 I  PRW: command='BACKEND_MESSAGE'
2013-01-02 23:54:00.077770 I  MythEvent: RECORDING_LIST_CHANGE ADD 13992 2013-01-02T23:54:00Z
2013-01-02 23:54:00.078130 I  CP Checking Storage group directories
2013-01-02 23:54:00.078148 I  CP Start Query
2013-01-02 23:54:00.078157 I  CP Query start size 0
2013-01-02 23:54:00.078171 I  CP Directory /MythTV/LiveTV/
2013-01-02 23:54:00.078210 I  CP Directory exists
2013-01-02 23:54:00.078236 I  CP Leaving Query
2013-01-02 23:54:00.078243 I  CP Start Query
2013-01-02 23:54:00.078249 I  CP Query start size 8
2013-01-02 23:54:00.078260 I  CP Directory /MythTV/fileserver/recordings/
2013-01-02 23:54:00.078283 I  CP Directory exists
2013-01-02 23:54:00.079002 I  CP Leaving Query
2013-01-02 23:54:00.079016 I  CP Start Query
2013-01-02 23:54:00.079024 I  CP Query start size 16
2013-01-02 23:54:00.079037 I  CP Directory /MythTV/mythfe3/recordings/
2013-01-02 23:54:00.079053 I  CP Directory doesn't exist
2013-01-02 23:54:00.079059 I  CP Leaving Query
2013-01-02 23:54:00.079064 I  CP Start Query
2013-01-02 23:54:00.079069 I  CP Query start size 16
2013-01-02 23:54:00.079078 I  CP Directory /MythTV/other/
2013-01-02 23:54:00.079089 I  CP Directory exists
2013-01-02 23:54:00.079107 I  CP Leaving Query
2013-01-02 23:54:00.079113 I  CP Start Query
2013-01-02 23:54:00.079119 I  CP Query start size 24
2013-01-02 23:54:00.079127 I  CP Directory /MythTV/satelite/recordings/
2013-01-02 23:54:00.079144 I  CP Directory exists
2013-01-02 23:54:00.079613 I  CP Leaving Query
2013-01-02 23:54:00.079642 I  CP start size 32
2013-01-02 23:54:00.079704 I  MythSocket(8be090:79): write -> 79 16      QUERY_FREE_SPACE
2013-01-02 23:54:00.081823 I  MythSocket(8be090:79): read  <- 79 686     BACKEND_MESSAGE[]:[]RECORDING_LIST_CHANGE UPDATE[]:[]CSI: Crime S...
2013-01-02 23:54:00.081884 E  MythSocket(8be090:79): Got MythEvent on non-event socket
2013-01-02 23:54:00.081891 E  PlaybackSock::SendReceiveStringList(): No response.
2013-01-02 23:54:00.081903 I  CP end size 81
2013-01-02 23:54:00.081976 I  CP2 Received 81
2013-01-02 23:54:00.081990 I  CP2Filesystem /MythTV/LiveTV
2013-01-02 23:54:00.082001 I  CP2Hostname mythbackend.mydomain.com
2013-01-02 23:54:00.082012 I  CP2Local 1
2013-01-02 23:54:00.082022 I  CP2Filesystem /MythTV/fileserver/recordings
2013-01-02 23:54:00.082027 I  CP2Hostname mythbackend.mydomain.com
2013-01-02 23:54:00.082033 I  CP2Local 0
2013-01-02 23:54:00.082040 I  CP2Filesystem /MythTV/other
2013-01-02 23:54:00.082045 I  CP2Hostname mythbackend.mydomain.com
2013-01-02 23:54:00.082050 I  CP2Local 1
2013-01-02 23:54:00.082058 I  CP2Filesystem /MythTV/satelite/recordings
2013-01-02 23:54:00.082068 I  CP2Hostname mythbackend.mydomain.com
2013-01-02 23:54:00.082081 I  CP2Local 0
2013-01-02 23:54:00.082097 I  CP2Filesystem RECORDING_LIST_CHANGE UPDATE
2013-01-02 23:54:00.082107 I  CP2Hostname BACKEND_MESSAGE
2013-01-02 23:54:00.082118 I  CP2Local 0
2013-01-02 23:54:00.082128 I  CP2Filesystem 13992
2013-01-02 23:54:00.082133 I  CP2Hostname Drama
2013-01-02 23:54:00.082138 I  CP2Local 1
2013-01-02 23:54:00.082146 I  CP2Filesystem 0
2013-01-02 23:54:00.082150 I  CP2Hostname 1357174500
2013-01-02 23:54:00.082156 I  CP2Local 0
2013-01-02 23:54:00.082163 I  CP2Filesystem 0
2013-01-02 23:54:00.082167 I  CP2Hostname 451
2013-01-02 23:54:00.082173 I  CP2Local 1
2013-01-02 23:54:00.082213 I  CP2Filesystem www.five.tv/r8is
2013-01-02 23:54:00.082219 I  CP2Hostname
2013-01-02 23:54:00.082226 I  CP2Local 0
2013-01-02 23:54:00.082234 I  CP2Filesystem 0
2013-01-02 23:54:00.082238 I  CP2Hostname 0
2013-01-02 23:54:00.082244 I  CP2Local 0

comment:7 Changed 6 years ago by paulh

Milestone: 0.26.10.27

comment:8 Changed 6 years ago by michael@…

Any progress on this, since upgrading from a smoothly working 0.26 to 0.27, with a slave backend connected, the master backend will eventually segfault. If slave backends are not connected the master backend is stable.

Final lines of MBE Log prior to crash.

Jul 28 19:44:44 mythone mythlogserver: mythbackend[24529]: I ProcessRequest? mainserver.cpp:1430 (HandleAnnounce?) MainServer::ANN Playback Jul 28 19:44:44 mythone mythlogserver: mythbackend[24529]: I ProcessRequest? mainserver.cpp:1432 (HandleAnnounce?) adding: mythone as a client (events: 0) Jul 28 19:44:44 mythone mythlogserver: mythbackend[24529]: I ProcessRequest? mainserver.cpp:1430 (HandleAnnounce?) MainServer::ANN Monitor Jul 28 19:44:44 mythone mythlogserver: mythbackend[24529]: I ProcessRequest? mainserver.cpp:1432 (HandleAnnounce?) adding: mythone as a client (events: 1) Jul 28 19:44:50 mythone mythlogserver: mythbackend[24529]: I Scheduler scheduler.cpp:2204 (HandleReschedule?) Scheduled 550 items in 14.5 = 1.28 match + 4.24 check + 9.02 place Jul 28 19:44:50 mythone mythlogserver: mythbackend[24529]: I Scheduler scheduler.cpp:2262 (HandleRunSchedulerStartup?) Scheduler: AUTO-Startup assumed Jul 28 19:44:52 mythone mythlogserver: mythbackend[24529]: I TVRecEvent tv_rec.cpp:1565 (HandlePendingRecordings?) TVRec[3]: ASK_RECORDING 3 0 0 0 Jul 28 19:44:52 mythone mythlogserver: mythbackend[24529]: I TVRecEvent tv_rec.cpp:1048 (HandleStateChange?) TVRec[3]: Changing from None to RecordingOnly? Jul 28 19:44:52 mythone mythlogserver: mythbackend[24529]: I TVRecEvent tv_rec.cpp:3597 (TuningCheckForHWChange) TVRec[3]: HW Tuner: 3->3 Jul 28 19:44:53 mythone mythlogserver: mythbackend[24529]: I TVRecEvent tv_rec.cpp:1565 (HandlePendingRecordings?) TVRec[1]: ASK_RECORDING 1 0 0 0 Jul 28 19:44:53 mythone mythlogserver: mythbackend[24529]: I TVRecEvent tv_rec.cpp:1565 (HandlePendingRecordings?) TVRec[2]: ASK_RECORDING 2 0 0 0 Jul 28 19:44:55 mythone mythlogserver: mythbackend[24529]: E Scheduler mythsocket.cpp:353 (SendReceiveStringList?) MythSocket?(1a30b20:83): Got MythEvent? on non-event socket Jul 28 19:44:55 mythone mythlogserver: mythbackend[24529]: E Scheduler playbacksock.cpp:94 (SendReceiveStringList?) PlaybackSock::SendReceiveStringList?(): No response. Jul 28 19:44:55 mythone mythlogserver: mythbackend[24529]: C CoreContext? signalhandling.cpp:305 (handleSignal) Received Segmentation fault: Code 128, PID 0, UID 0, Value 0x7f3bae625838 Jul 28 19:44:55 mythone mythlogserver: mythbackend[24529]: E ProcessRequest? mainserver.cpp:873 (ProcessRequestWork?) Unknown command: tv01

Log snipped from SBE as MBE Crashed.

Jul 28 19:44:22 tv01 mythlogserver: mythbackend[1054]: E ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) Got 'UNKNOWN_COMMAND' out of sequence. Jul 28 19:44:24 tv01 mythlogserver: mythbackend[1054]: N CoreContext? mainserver.cpp:6207 (reconnectTimeout) Connecting to master server: 10.0.11.230:6543 Jul 28 19:44:24 tv01 mythlogserver: mythbackend[1054]: E MythSocketThread?(-1) mythsocket.cpp:639 (ConnectToHostReal?) MythSocket?(cc8240:-1): Failed to connect to (10.0.11.230:6543) Connection refused

comment:9 Changed 6 years ago by stuartm

Priority: minorblocker

comment:10 Changed 6 years ago by Jean-Yves Avenard <jyavenard@…>

Resolution: fixed
Status: acceptedclosed

In d6b9469bc86666f02f070d4eb8c546a029b4ec43/mythtv:

Make sure the result is a list of exactly 8 as that’s what is expected in followup code.

Fixes #11318

comment:11 Changed 6 years ago by davescammell@…

I updated to latest of the master branch this afternoon v0.27-beta-54-g0614c98 but I am seeing issues, log snippets below:

log from the MBE:

2013-08-24 21:21:53.198756 E [15197/15252] FreeSpaceUpdater? playbacksock.cpp:101 (SendReceiveStringList?) - PlaybackSock::SendReceiveStringList?(): Respo nse too short 2013-08-24 21:21:53.261669 E [15197/15252] FreeSpaceUpdater? mythsocket.cpp:353 (SendReceiveStringList?) - MythSocket?(a86aa50:69): Got MythEvent? on non-e vent socket 2013-08-24 21:21:53.261691 E [15197/15252] FreeSpaceUpdater? playbacksock.cpp:94 (SendReceiveStringList?) - PlaybackSock::SendReceiveStringList?(): No res ponse. 2013-08-24 21:21:53.261708 E [15197/15252] FreeSpaceUpdater? playbacksock.cpp:312 (IsBusy?) - PlaybackSock?: IsBusy?: QUERY_REMOTEENCODER 24 gave us no res ponse. 2013-08-24 21:21:53.263303 I [15197/20236] MythSocketThread?(69) mainserver.cpp:434 (readyRead) - readyRead ignoring, expecting reply 2013-08-24 21:21:53.269625 E [15197/15298] ProcessRequest? mainserver.cpp:873 (ProcessRequestWork?) - Unknown command: 0 2013-08-24 21:22:08.200865 E [15197/15252] FreeSpaceUpdater? playbacksock.cpp:101 (SendReceiveStringList?) - PlaybackSock::SendReceiveStringList?(): Respo nse too short 2013-08-24 21:22:13.361751 E [15197/15252] FreeSpaceUpdater? mythsocket.cpp:353 (SendReceiveStringList?) - MythSocket?(a86aa50:69): Got MythEvent? on non-e vent socket 2013-08-24 21:22:13.361771 E [15197/15252] FreeSpaceUpdater? playbacksock.cpp:94 (SendReceiveStringList?) - PlaybackSock::SendReceiveStringList?(): No res ponse. 2013-08-24 21:22:13.361788 E [15197/15252] FreeSpaceUpdater? playbacksock.cpp:312 (IsBusy?) - PlaybackSock?: IsBusy?: QUERY_REMOTEENCODER 19 gave us no res ponse.

SBE: 2013-08-24 21:20:42.917631 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:20:52.966172 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:21:03.013848 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:21:13.057860 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:22:08.226112 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:28:37.213620 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:28:38.216456 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence. 2013-08-24 21:28:45.330164 E [5522/6572] ProcessRequest? mainserver.cpp:869 (ProcessRequestWork?) - Got 'UNKNOWN_COMMAND' out of sequence.

I think this is affecting recording and possibly frontend usage, not had much time to examine it, certainly there seem to be a lot of failed recordings. Happy to open a further ticket if wanted? dave s

comment:12 Changed 6 years ago by JYA

while it's a consequence of not crashing anymore, it's not the same problem... so open a new ticket

Note: See TracTickets for help on using tickets.