SBE termination cases MBE mutex crash

[enorm1@…]

My master backend is crashing when the slave backend is terminated. This does not always occur but rougly every other restart of the slave backend will cause this segfault.

I don't know if this has anything to do with anything but the capture-cards of the slave has higher priority than the card of the mbe.

I'm using:

• ​http://svn.mythtv.org/svn/branches/release-0-18-fixes/mythtv

• gentoo x11-libs/qt-3.3.4-r8

• gentoo dev-db/mysql-4.1.14

on both servers.

The problem occurs in 0.18.1 as well (that's why i switched to 0.18.fixes)

I've been trying to look into the code, but the PlaybackSock?.sockLock attribute seems 100% legit. It's a private attribute only used by one class method.

Browsing the code it looks like the PlaybackSock? instance is deleted by MainServer::endConnection() when the slave backend terminates. This while the schedules thread is still using the instance. A simple mutex would probably solve the problem.

To me this problem is critical since i intend to run the slave backend on a "on-demand" basis, and there is no point in developing a scheduler addon (that starts the sbe when needed), if the mbe crashes like this.

(gdb) run
Starting program: /usr/bin/mythbackend --verbose quiet --logfile /var/log/mythtv/mythbackend.log
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 26094)]
Qt: gdb: -nograb added to command-line options.
         Use the -dograb option to enforce grabbing.
[New Thread 32769 (LWP 26100)]
[New Thread 16386 (LWP 26101)]
[New Thread 32771 (LWP 26103)]
[New Thread 49156 (LWP 26104)]
[New Thread 65541 (LWP 26105)]
[New Thread 81926 (LWP 26106)]
[New Thread 98311 (LWP 26107)]
[New Thread 114696 (LWP 26110)]
[New Thread 131081 (LWP 26111)]
[New Thread 147466 (LWP 26112)]
[New Thread 163851 (LWP 26113)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 26103)]
0x45525f59 in ?? ()


(gdb) thread apply all bt full
Thread 12 (Thread 163851 (LWP 26113)):
#0  0xb66f2094 in __pthread_sigsuspend () from /lib/libpthread.so.0
No symbol table info available.
#1  0xb66f1ed9 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
No symbol table info available.
#2  0xb66edfdb in pthread_cond_wait@GLIBC_2.0 () from /lib/libpthread.so.0
No symbol table info available.
#3  0xb2fd1e08 in ?? ()
No symbol table info available.
#4  0x00000000 in ?? ()
No symbol table info available.
#5  0x080fdea8 in ?? ()
No symbol table info available.
#6  0xb66ede80 in pthread_cond_destroy@GLIBC_2.0 () from /lib/libpthread.so.0
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
#0  0x45525f59 in ?? ()
(gdb) st
start     step      stepi     stepping  stop


(gdb) backtrace
#0  0x45525f59 in ?? ()
#1  0xb6e548c8 in QMutex::unlock () from /usr/qt/3/lib/libqt-mt.so.3
#2  0x08095023 in PlaybackSock::SendReceiveStringList (this=0x80e1218, strlist=@0xb57d1ba0) at playbacksock.cpp:60
#3  0x08095725 in PlaybackSock::IsBusy (this=0x80e1218, capturecardnum=1) at playbacksock.cpp:145
#4  0x0805d9ee in EncoderLink::IsBusy (this=0x80f3460) at encoderlink.cpp:65
#5  0x0809d5ed in Scheduler::RunScheduler (this=0x80f3db0) at scheduler.cpp:1127
#6  0x0809e553 in Scheduler::SchedulerThread (param=0x80f3db0) at scheduler.cpp:1293
#7  0xb66ef18e in pthread_start_thread () from /lib/libpthread.so.0
#8  0xb66ef334 in pthread_start_thread_event () from /lib/libpthread.so.0
#9  0xb659eaaa in clone () from /lib/libc.so.6
(gdb)

[Isaac Richards]

Pretty sure that this is fixed in trunk - please try to reproduce there.