Opened 13 years ago

Closed 13 years ago

#5614 closed defect (fixed)

Unexplained intermittent high backend cpu usage

Reported by:… Owned by: Isaac Richards
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: medium Keywords: ct
Cc: Ticket locked: no


I'm running current SVN (18132), and everything seems fine for the most part, however it seems after some recordings complete, the backend CPU usage pegs, frontend CPU usage goes high, and the user interface is unresponsive, yet live-tv viewing continues to run fine, but no control by keyboard or remote. Is anybody else experiencing this? I have reset the log settings to "most" and will supply extracts of the logs as soon as I can get something meaningful. If anybody has suggestions on a more appropriate verbosity, I'd like to know so I don't get such huge files.

Attachments (1)

mythbackend.log (20.1 KB) - added by anonymous 13 years ago.

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by anonymous

Attachment: mythbackend.log added

comment:1 Changed 13 years ago by…

Well, here's more. The attached file is from the slave backend, as it appears it crashed at the end of a recording (2 shows recording on slave backend with 2 PVR150). The frontend has a single PVR150, which was viewing live-tv at the time.

comment:2 Changed 13 years ago by anonymous

I just had this happen to me, too. Recording on a PVR-150. My PVR-350, pcHDTV-5500 and HDHR were all idle. All in one box. Frontend played just fine, but could not interact at all until I restarted both the frontend and backend.

I'm running trunk with the coreavc patch but this is only my second day with this config so I probably won't be much help in diagnosing.

comment:3 Changed 13 years ago by…

I have updated my QT from 4.3.x to 4.4.1 and have upgraded to latest SVN 18144 and am still getting random backend segfaults, but see nothing in the logs. I've recompiled with debug info, and am running backend in gdb to try to get a backtrace, and of course, so far, no segfaults. As soon as something happens, hopefully I'll have some usable information.

comment:4 Changed 13 years ago by…

Ok, Here we go. I was watching Live-TV, and then exited and then tried to go into "Watch Recordings", at which time the backend segfaulted. Prior to the segfault, there were many "QMutex::lock(): cv wait failure:" messages. I will get all the pertinent debug info together and will attach it. Fortunately, I caught this in gdb with debug compiled into mythtv.

comment:5 Changed 13 years ago by…

Well.... The backtrace in GDB probably doesn't help much, but here it is.

QMutex::lock(): cv wait failure: QMutex::lock(): cv wait failure: QMutex::lock(): cv wait failure: QMutex::lock(): cv wait failure: QMutex::lock(): cv wait failure: QMutex::lock(): cv wait failure:

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x45177950 (LWP 7453)] 0x00007f12c6c97ffc in _int_malloc () from /lib/ (gdb) bt #0 0x00007f12c6c97ffc in _int_malloc () from /lib/ #1 0x00007f12c6c99744 in _int_realloc () from /lib/ #2 0x00007f12c6c9a6af in realloc () from /lib/ #3 0x00007f12c7fc9422 in QListData::realloc ()

from /usr/lib/qt4/

#4 0x00007f12c7fc9653 in QListData::append () from /usr/lib/qt4/ #5 0x00007f12c7fbe9f5 in QList<QString>::append ()

from /usr/lib/qt4/

#6 0x00007f12c7fe92a6 in QString::split () from /usr/lib/qt4/ #7 0x00007f12c7fe93a0 in QString::section () from /usr/lib/qt4/ #8 0x00000000004a6c1c in QString::section (this=0x45176d70, asep={ucs = 58},

astart=1, aend=-1, aflags={i = 1159163584}) at /usr/include/qt4/QtCore/qstring.h:733

#9 0x00007f12cdaa31ff in SSDP::ProcessData? (this=0x8db540, pSocket=0x8db390)

at ssdp.cpp:283

#10 0x00007f12cdaa3b9c in SSDP::run (this=0x8db540) at ssdp.cpp:228 #11 0x00007f12c7fa937b in QThreadPrivate::start ()

from /usr/lib/qt4/

#12 0x00007f12c791d017 in start_thread () from /lib/ #13 0x00007f12c6cf0fdd in clone () from /lib/ #14 0x0000000000000000 in ?? () (gdb)

comment:6 Changed 13 years ago by…

After doing a little research on the cv wait failure, there wasn't much info out there on it (at least in google), but I see the following:

Important: when adding a function wrapper to this file, remember to add a test case to tc20_verifywrap.c. A common cause of failure is for wrappers to not engage on different distros, and tc20_verifywrap essentially checks that each wrapper is really doing something.

So, the point is, my master box is Gentoo Linux saruman 2.6.26-gentoo #1 SMP PREEMPT Tue Aug 12 18:54:32 CDT 2008 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel? GNU/Linux

and my slave box is Ubuntu. Linux gandalf 2.6.24-20-generic #1 SMP Mon Jul 28 13:49:52 UTC 2008 i686 GNU/Linux

Obviously different platforms. Thought this might be important info.

comment:7 Changed 13 years ago by…

Found one problem, need to rebuild with -ggdb CFLAG set.

comment:8 Changed 13 years ago by…

I have just rebuilt with latest SVN (18153), and am continuing the backend in gdb. It appears that Janne's release 18152 very likely is responsible for resolving this issue, as the output of mythbackend appears to be 100% clean, with no random errors that I had been seeing prior to that release. I will continue to monitor and excercise the recorders to see if I can find fault, but looks great so far. Thanks, Janne!

comment:9 Changed 13 years ago by…

I am pretty confident at this point that this ticket can be closed. I've done several simultaneous recordings/live-tv viewing, etc. I have not seen any unusual error messages in the backend logs other than the occaisional "AFD unknown decoding error", [mpeg2video @ 0x7fdf28a39cf0]current_picture not initialized" and some instances of:

2008-08-13 23:36:19.151 adding: saruman as a client (events: 0) 2008-08-13 23:38:37.199 adding: saruman as a client (events: 0) 2008-08-13 23:38:39.136 adding: saruman as a client (events: 0) 2008-08-13 23:47:04.552 AutoExpire?: CalcParams?(): Max required Free Space: 11.0 GB w/freq: 15 min 2008-08-13 23:57:24.746 adding: saruman as a client (events: 0) 2008-08-13 23:57:27.166 adding: saruman as a client (events: 0) 2008-08-13 23:58:37.893 adding: saruman as a client (events: 0)

but these seem unrelated to the other problem.

comment:10 Changed 13 years ago by Shane Shrybman

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.