[mythtv] SIGSEGV from ref-counting race condition in PlaybackSock?

[Russell Mora]

Hi All,

I just experienced a backend SIGSEGV and I thought before I get too involved
in debugging it I should check with the list to see if any experts can
identify the problem.  I am running SVN Rev 14309 in what is effectively an
optimised build with debug symbols (I'm using the release-dbg profile from
http://svn.mythtv.org/trac/ticket/3589).  Also I have a master backend
running also the frontend and a remote machine also running both BE/FE - the
dump is of the master BE.  Here is what I see in GDB:

myth_master ~ # gdb /usr/local/bin/mythbackend /core.4224
GNU gdb 6.6
<...>
Core was generated by `/usr/local/bin/mythbackend --verbose
general,important --logfile /var/log/mytht'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002aea07167170 in QMutex::lock () from /usr/qt/3/lib/libqt-mt.so.3
(gdb) bt
#0  0x00002aea07167170 in QMutex::lock () from /usr/qt/3/lib/libqt-mt.so.3
#1  0x00002aea05e36b97 in MythSocket::UpRef (this=0x69006e006f004d) at
mythsocket.cpp:61
#2  0x000000000047d2ce in PlaybackSock::SendReceiveStringList
(this=0x1be0750, strlist=@0x4d018540) at playbacksock.cpp:63
#3  0x000000000047f8d0 in PlaybackSock::GetDiskSpace (this=0x1be0750,
o_strlist=@0x4d018a40) at playbacksock.cpp:99
#4  0x00000000004b96f2 in BackendQueryDiskSpace (strlist=@0x4d018a40,
encoderList=0x607460, consolidated=false, allHosts=true) at backendutil.cpp
:137
#5  0x00000000004ba2e8 in GetFilesystemInfos (tvList=0x607460,
fsInfos=@0x4d018c40) at backendutil.cpp:227
#6  0x0000000000414f73 in AutoExpire::CalcParams (this=0x751b00) at
autoexpire.cpp:115
#7  0x0000000000417faa in SpawnUpdateThread (autoExpireInstance=0x751b00) at
autoexpire.cpp:933
#8  0x00002aea07c2b257 in ?? () from /lib/libpthread.so.0
#9  0x00002aea0828bafd in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(gdb) frame 2
#2  0x000000000047d2ce in PlaybackSock::SendReceiveStringList
(this=0x1be0750, strlist=@0x4d018540) at playbacksock.cpp:63
63          sock->UpRef();
(gdb) print this
$18 = (PlaybackSock * const) 0x1be0750
(gdb) print *this
$19 = {_vptr.PlaybackSock = 0x20004e004e0041, sock = 0x69006e006f004d,
hostname = {static null = {
      static null = <same as static member of an already seen type>, d =
0x60bda0, static shared_null = 0x60bda0}, d = 0x200072006f0074,
    static shared_null = 0x60bda0}, ip = {static null = {static null = <same
as static member of an already seen type>, d = 0x60bda0,
      static shared_null = 0x60bda0}, d = 0x6800740079006d, static
shared_null = 0x60bda0}, local = 95, events = false, blockshutdown = 102,
  backend = false, sockLock = <incomplete type>, expectingreply = false,
disconnected = true, refCount = -1, m_parent = 0x7601e0}
(gdb) print *this->sock
Cannot access memory at address 0x69006e006f004d
(gdb) list
58      }
59
60      bool PlaybackSock::SendReceiveStringList(QStringList &strlist)
61      {
62          sock->Lock();
63          sock->UpRef();
64
65          sockLock.lock();
66          expectingreply = true;
67
(gdb)


Note that the sock member is invalid and that the refCount of the
PlaybackSock is -1.  Interestingly enough there is another thread that is
also using the exact same PlaybackSock, and is pretty much in the same code:


(gdb) thread 21
[Switching to thread 21 (process 4347)]#0  0x00002aea07c31a98 in ?? () from
/lib/libpthread.so.0
(gdb) bt
#0  0x00002aea07c31a98 in ?? () from /lib/libpthread.so.0
#1  0x00002aea07c2dbdb in ?? () from /lib/libpthread.so.0
#2  0x00002aea07c2d533 in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x00002aea071672bd in QRealMutexPrivate::lock () from
/usr/qt/3/lib/libqt-mt.so.3
#4  0x00002aea05e28510 in MythSocket::Lock (this=<value optimized out>) at
mythsocket.cpp:564
#5  0x000000000047d2c1 in PlaybackSock::SendReceiveStringList
(this=0x1be0750, strlist=@0x0) at playbacksock.cpp:62
#6  0x000000000047f8d0 in PlaybackSock::GetDiskSpace (this=0x1be0750,
o_strlist=@0x448076a0) at playbacksock.cpp:99
#7  0x00000000004b96f2 in BackendQueryDiskSpace (strlist=@0x448076a0,
encoderList=0x607460, consolidated=false, allHosts=true) at backendutil.cpp
:137
#8  0x00000000004ba2e8 in GetFilesystemInfos (tvList=0x607460,
fsInfos=@0x44807920) at backendutil.cpp:227
#9  0x000000000041d560 in AutoExpire::ExpireRecordings (this=0x751b00) at
autoexpire.cpp:325
#10 0x0000000000425a44 in AutoExpire::RunExpirer (this=0x751b00) at
autoexpire.cpp:275
#11 0x0000000000425a59 in AutoExpire::ExpirerThread (param=0x2aaab13a4f38)
at autoexpire.cpp:547
#12 0x00002aea07c2b257 in ?? () from /lib/libpthread.so.0
#13 0x00002aea0828bafd in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()
(gdb) frame 5
#5  0x000000000047d2c1 in PlaybackSock::SendReceiveStringList
(this=0x1be0750, strlist=@0x0) at playbacksock.cpp:62
62          sock->Lock();
(gdb) print this
$20 = (PlaybackSock * const) 0x1be0750
(gdb) print *this
$21 = {_vptr.PlaybackSock = 0x20004e004e0041, sock = 0x69006e006f004d,
hostname = {static null = {
      static null = <same as static member of an already seen type>, d =
0x60bda0, static shared_null = 0x60bda0}, d = 0x200072006f0074,
    static shared_null = 0x60bda0}, ip = {static null = {static null = <same
as static member of an already seen type>, d = 0x60bda0,
      static shared_null = 0x60bda0}, d = 0x6800740079006d, static
shared_null = 0x60bda0}, local = 95, events = false, blockshutdown = 102,
  backend = false, sockLock = <incomplete type>, expectingreply = false,
disconnected = true, refCount = -1, m_parent = 0x7601e0}
(gdb) list
57          return false;
58      }
59
60      bool PlaybackSock::SendReceiveStringList(QStringList &strlist)
61      {
62          sock->Lock();
63          sock->UpRef();
64
65          sockLock.lock();
66          expectingreply = true;
(gdb)


I didn't notice any other interesting threads - the only thing in the
backend log at the time of the dump is:

2007-09-30 23:57:20.264 Event socket closed. No connection to the backend.
2007-09-30 23:57:20.264 Event socket closed. No connection to the backend.


I'll continue to investigate and open a ticket when I isolate the problem,
but if anyone wants to short-circuit the effort I won't complain :-)

Cheers,
Russell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20071001/26b8348b/attachment.htm