[mythtv-users] mythfilldatabase segfaults

[Pasha Golovko]

On Thu, Dec 3, 2009 at 11:16 AM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 12/03/2009 01:41 PM, Johnny Walker wrote:
>
>> On Thu, Dec 3, 2009 at 11:54 AM, Johnny Walker wrote:
>>
>>
>>> Ok - I actually searched trac for this one to make sure there's not an
>>> obvious open ticket on this.
>>>
>>> I'm seeing these in my /var/log/messages regularly:
>>>
>>> Dec  3 08:16:19 mythserver kernel: [66657.267033]
>>> mythfilldatabas[3960]: segfault at 84300020 ip 007eaf3c sp b6884c90
>>> error 4 in libmythdb-0.22.so.0.22.0[7b4000+97000]
>>>
>>>
>> I mean this is happening often - at least to me:
>>
>> root at mythserver:/var/log# grep -i segfault messages*
>>
>> messages:Nov 29 07:00:27 mythserver kernel: [293964.131646]
>> mythfilldatabas[5791]: segfault at 1d2 ip 00820f3c sp b5943c90 error 4
>> in libmythdb-0.22.so.0.22.0[7ea000+97000
>>
>
> Can you get a good (with debug symbols) backtrace?
> http://www.mythtv.org/wiki/Debugging


Here is the stack-trace with the log snippet right before the crash:

===============================================================
| Attempting to contact the master backend for rescheduling.  |
| If the master is not running, rescheduling will happen when |
| the master backend is restarted.                            |
===============================================================
2009-11-17 09:00:23.746 MythContext: Connecting to backend server:
192.168.2.3:6543 (try 1 of 1)
2009-11-17 09:00:23.748 Using protocol version 50
2009-11-17 09:00:23.749 MainServer::ANN Monitor
2009-11-17 09:00:23.754 adding: ares as a client (events: 0)
2009-11-17 09:00:23.755 MainServer::ANN Monitor
2009-11-17 09:00:23.764 adding: ares as a client (events: 1)
2009-11-17 09:00:23.768 Reschedule requested for id -1.
2009-11-17 09:00:23.769 Received a remote 'Clear Cache' request
2009-11-17 09:00:23.856 Invalid search key in recordid 187
[New Thread 0xb279bb90 (LWP 21950)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb279bb90 (LWP 21950)]
0xb662b924 in MythContext::ClearSettingsCache (this=0x92ff1a0,
    myKey=@0xb279ad14) at mythcontext.cpp:1900
1900        d->m_database->ClearSettingsCache(myKey);
#0  0xb662b924 in MythContext::ClearSettingsCache (this=0x92ff1a0,
    myKey=@0xb279ad14) at mythcontext.cpp:1900
#1  0xb662c012 in MythContext::readyRead (this=0x92ff1a0, sock=0x93331e0)
    at mythcontext.cpp:2171
#2  0xb62c318c in MythSocketThread::ReadyToBeRead (this=0x92aada8,
    sock=0x93331e0) at mythsocketthread.cpp:168
#3  0xb62c6502 in MythSocketThread::run (this=0x92aada8)
    at mythsocketthread.cpp:355
#4  0xb508596e in ?? () from /usr/lib/libQtCore.so.4
#5  0xb5f314ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6  0xb4e8b49e in clone () from /lib/tls/i686/cmov/libc.so.6

I've seen this problem for a while and even instrumented mythfilldatabase to
run inside gdb to produce stack-trace (when running mythfilldatabase
manually I could never get it to crash).

Thanks,
Pasha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20091203/3fca4276/attachment.htm>