[mythtv-users] MySQL related BE deadlocks - collective wisdom needed

[Brian J. Murrell]

There are a couple of points worth noting in regard to my lockups...

My lockups typically exhibit:

2011-07-31 10:31:31.179 Protocol version check failure.
			The response to MYTH_PROTO_VERSION was empty.
			This happens when the backend is too busy to respond,
			or has deadlocked in due to bugs or hardware failure.
2011-07-31 10:31:31.180 Unable to find active recorder for this
recording, realtime flagging will not be enabled.

in the BE logs and no FEs can connect at that time.

This invariably happens when recording so it's somehow related to what
goes on during recordings (of course which is heavy on mysql access with
the associated commflagging happening).

I discovered yesterday that if I wait long enough (not sure how long or
what events correlate, yet) the deadlock will resolve itself and FEs can
connect again.

My BE is at this moment locked up and FEs cannot connect.  I am
recording a single program from my HVR-950Q on clearqam.

The stack trace interestingly enough has evidence of EIT scanning:

Thread 28 (Thread 0xb461cb70 (LWP 1802)):
#0  0x008ac422 in __kernel_vsyscall ()
No symbol table info available.
#1  0x0028b342 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:179
No locals.
#2  0x08c0a20f in QWaitConditionPrivate::wait (this=0x9f30f98,
mutex=0x9f30f78, time=400) at thread/qwaitcondition_unix.cpp:85
        tv = {tv_sec = 1312123834, tv_usec = 503275}
        ti = {tv_sec = 1312123834, tv_nsec = 903275000}
        code = <value optimized out>
#3  QWaitCondition::wait (this=0x9f30f98, mutex=0x9f30f78, time=400) at
thread/qwaitcondition_unix.cpp:159
        returnValue = <value optimized out>
#4  0x0100dc44 in EITScanner::RunEventLoop (this=0x9f30f78) at
eitscanner.cpp:159
        list_size = 0
        rate = 1
        sz = {2000, 1800, 1600, 1400, 1200}
        rt = {0, 0.200000003, 0.400000006, 0.600000024, 0.800000012}
        t = {m_timer = {mds = -1}, m_running = false}
        eitCount = 0
#5  0x0100ca78 in EITThread::run (this=0x9f30f88) at eitscanner.cpp:30
No locals.
#6  0x08c0932e in QThreadPrivate::start (arg=0x9f30f88) at
thread/qthread_unix.cpp:248
        data = 0x9f3aba0
#7  0x0028696e in start_thread (arg=0xb461cb70) at pthread_create.c:300
        __res = <value optimized out>
        __ignore1 = <value optimized out>
        __ignore2 = <value optimized out>
        pd = 0xb461cb70
        now = <value optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {2715636, 0, 4001536,
-1268661208, 1607656650, -863626846}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <value optimized out>
        robust = <value optimized out>
        freesize = <value optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#8  0x020caa4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
No locals.

but I have disabled EIT scanning per another theory about these lockups.

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110731/3dee9c93/attachment.bin