[mythtv-users] Reproducible Backend Crash (0.18.fixes)

[Erik Andersson]

E Norm wrote:

> 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'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.
>
> Oh, maybe the entire PlaybackSock instance is deleted when
> the slave backend terminates while some other thread is
> using it..
>
> Could someone take a look at this?
>
> regards
> /Dan
>
>
> (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 at 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 at 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)
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
 From what i can understand of the code the MainServer::endConnection 
deletes
the PlaybackSock instance without checking any thread locks whatsoever.
Then the scheduler thread would naturally run into problems when it is 
periodically checking
PlaybackSock::IsBusy...