mythfilldatabase segfaulting periodically..

[damian@…]

This is a new ticket as requested ny nigel as a follow up to ​http://svn.mythtv.org/trac/ticket/4249#comment:13

The problem is still persisting as of latest SVN.. Note : This is on a dual core system. Also works about 25% of time..

damian@mythtv-box:~$ mythfilldatabase -v all
2007-12-20 16:17:39.285 Using runtime prefix = /usr/local
2007-12-20 16:17:39.286 Using localhost value of mythtv-box
2007-12-20 16:17:39.287 MCP::DefaultUPnP() - config.xml has default PIN '2925' and host USN: uuid:785fe75f-4cd9-470e-a19e-223f7feddbc5::urn:schemas-mythtv-org:device:MasterMediaServer:1
2007-12-20 16:17:39.287 Setting UPnP client for backend autodiscovery...
2007-12-20 16:17:39.287 UPnp - Constructor
2007-12-20 16:17:39.287 ThreadPool:AddWorkerThread - HTTP_WorkerThread
2007-12-20 16:17:39.287 UPnp::Initialize - Begin
2007-12-20 16:17:39.288 UPnp::Initialize - Starting TaskQueue
2007-12-20 16:17:39.288 UPnp::Initialize - Creating SSDP Thread at port 6549
2007-12-20 16:17:39.288 UPnp::Initialize - End
2007-12-20 16:17:39.288 UPnp::Start - Starting SSDP Thread (Multicast)
2007-12-20 16:17:39.288 UPnp::Start - Enabling Notifications
2007-12-20 16:17:39.288 SSDP::EnableNotifications() - creating new task
2007-12-20 16:17:39.288 SSDP::EnableNotifications() - sending NTS_byebye
2007-12-20 16:17:39.288 LookupUDN(urn:schemas-upnp-org:device:MythContextClient:1) sName=UPnP/UDN/MythContextClient, sUDN=
2007-12-20 16:17:39.288 UPnpNotifyTask::SendNotifyMsg : 239.255.255.250 : upnp:rootdevice : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd::upnp:rootdevice
2007-12-20 16:17:39.289 UPnpNotifyTask::SendNotifyMsg() - address: 192.168.1.100
2007-12-20 16:17:39.300 UPnpNotifyTask::SendNotifyMsg : 239.255.255.250 : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd
2007-12-20 16:17:39.300 UPnpNotifyTask::SendNotifyMsg() - address: 192.168.1.100
2007-12-20 16:17:39.476 UPnpNotifyTask::SendNotifyMsg : 239.255.255.250 : urn:schemas-upnp-org:device:MythContextClient:1 : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd::urn:schemas-upnp-org:device:MythContextClient:1
2007-12-20 16:17:39.476 UPnpNotifyTask::SendNotifyMsg() - address: 192.168.1.100
2007-12-20 16:17:39.534 SSDP::EnableNotifications() - sending NTS_alive
2007-12-20 16:17:39.534 SSDP::EnableNotifications() - Task added to UPnP queue
2007-12-20 16:17:39.534 UPnp::Start - Returning
2007-12-20 16:17:39.590 UPnpNotifyTask::SendNotifyMsg : 239.255.255.250 : upnp:rootdevice : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd::upnp:rootdevice
2007-12-20 16:17:39.590 UPnpNotifyTask::SendNotifyMsg() - address: 192.168.1.100
2007-12-20 16:17:39.603 UPnPconnect() - Trying host at http://192.168.1.100:6544/getDeviceDesc
2007-12-20 16:17:39.603 postHttp: grabbing: http://192.168.1.100:6544/Myth
2007-12-20 16:17:39.604 HttpComms::stateChanged: connecting (2)
2007-12-20 16:17:39.617 HttpComms::stateChanged: sending (3)
2007-12-20 16:17:39.627 HttpComms::stateChanged: reading (4)
2007-12-20 16:17:39.628 Got HTTP response: 200:OK
2007-12-20 16:17:39.628 Keys: accept-ranges,cache-control,connection,content-length,content-type,date,ext,server
2007-12-20 16:17:39.628 HttpComms::stateChanged: connected (5)
2007-12-20 16:17:39.628 done: 759 bytes
2007-12-20 16:17:39.638 Got 759 bytes from url: 'http://192.168.1.100:6544/Myth'
2007-12-20 16:17:39.638 <?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetConnectionInfoResponse xmlns:u="urn:schemas-mythtv-org:service:MythTv:1">
<Info>&lt;Database&gt;&lt;Host&gt;localhost&lt;/Host&gt;&lt;Port&gt;0&lt;/Port&gt;&lt;UserName&gt;mythtv&lt;/UserName&gt;&lt;Password&gt;muaU8KrQ&lt;/Password&gt;&lt;Name&gt;mythconverg&lt;/Name&gt;&lt;Type&gt;QMYSQL3&lt;/Type&gt;&lt;/Database&gt;&lt;WOL&gt;&lt;Enabled&gt;0&lt;/Enabled&gt;&lt;Reconnect&gt;0&lt;/Reconnect&gt;&lt;Retry&gt;5&lt;/Retry&gt;&lt;Command&gt;echo &apos;WOLsqlServerCommand not set&apos;&lt;/Command&gt;&lt;/WOL&gt;</Info>
</u:GetConnectionInfoResponse>
</s:Body>
</s:Envelope>
2007-12-20 16:17:39.639 UPnPconnect() - Got database hostname: localhost
2007-12-20 16:17:39.647 New DB connection, total: 1
2007-12-20 16:17:39.651 Connected to database 'mythconverg' at host: localhost
2007-12-20 16:17:39.651 Closing DB connection named 'DBManager0'
2007-12-20 16:17:39.652 Clearing Settings Cache.
2007-12-20 16:17:39.652 Deleting UPnP client...
2007-12-20 16:17:39.652 UPnp - Destructor
2007-12-20 16:17:39.652 UPnp::CleanUp() - disabling SSDP notifications
2007-12-20 16:17:39.652 UPnpNotifyTask::SendNotifyMsg : 239.255.255.250 : upnp:rootdevice : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd::upnp:rootdevice
2007-12-20 16:17:39.652 UPnpNotifyTask::SendNotifyMsg() - address: 192.168.1.100
2007-12-20 16:17:39.825 UPnpNotifyTask::SendNotifyMsg : 239.255.255.250 : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd : uuid:8653b81e-9ddb-4d6b-b9ed-eb25f4425fbd
2007-12-20 16:17:39.825 UPnpNotifyTask::SendNotifyMsg() - address: 192.168.1.100
Segmentation fault (core dumped)

[stuartm]

We need a backtrace. http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2

[panachoi@…]

Don't no if this is the same, but I'm having similar problems. mythfilldatabase segfaults about 25% of the time -- less if I use -v all on the command line. Here's the output from gdb, for what its worth:

Starting program: /usr/local/bin/mythfilldatabase [Thread debugging using libthread_db enabled] [New Thread -1247524176 (LWP 23459)] Qt: gdb: -nograb added to command-line options.

Use the -dograb option to enforce grabbing.

2007-12-21 14:07:25.886 Using runtime prefix = /usr/local 2007-12-21 14:07:25.886 Empty LocalHostName?. 2007-12-21 14:07:25.887 Using localhost value of d915 2007-12-21 14:07:25.938 New DB connection, total: 1 2007-12-21 14:07:25.942 Connected to database 'mythconverg' at host: localhost 2007-12-21 14:07:25.943 Closing DB connection named 'DBManager0' 2007-12-21 14:07:25.943 Connected to database 'mythconverg' at host: localhost 2007-12-21 14:07:25.948 New DB connection, total: 2 2007-12-21 14:07:25.948 Connected to database 'mythconverg' at host: localhost 2007-12-21 14:07:26.009 Source 1 configured to use only the broadcasted guide data. Skipping. 2007-12-21 14:07:26.020 Source 2 configured to use only the broadcasted guide data. Skipping. 2007-12-21 14:07:26.021 Data fetching complete. 2007-12-21 14:07:26.021 Adjusting program database end times. 2007-12-21 14:07:26.089 0 replacements made 2007-12-21 14:07:26.089 Marking generic episodes. 2007-12-21 14:07:26.151 Found 0 2007-12-21 14:07:26.151 Marking repeats. 2007-12-21 14:07:26.208 Found 0 2007-12-21 14:07:26.208 Unmarking new episode rebroadcast repeats. 2007-12-21 14:07:26.208 Found 0 2007-12-21 14:07:26.391 Marking episode first showings. 2007-12-21 14:07:30.834 Found 5232 2007-12-21 14:07:30.834 Marking episode last showings. 2007-12-21 14:07:35.353 Found 5232 2007-12-21 14:07:35.355 =============================================================== | Attempting to contact the master backend for rescheduling. | | If the master is not running, rescheduling will happen when | | the master backend is restarted. | =============================================================== 2007-12-21 14:07:35.357 Connecting to backend server: 192.168.141.114:6543 (try 1 of 5) 2007-12-21 14:07:35.358 Using protocol version 36 [New Thread -1251173488 (LWP 23460)] 2007-12-21 14:07:35.711 Received a remote 'Clear Cache' request

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1251173488 (LWP 23460)]
0x0817a6e8 in ?? ()
(gdb) where
#0  0x0817a6e8 in ?? ()
#1  0xb6640ad2 in QMutex::lock () from /usr/lib/libqt-mt.so.3
#2  0xb6c18872 in MythContext::ClearSettingsCache (this=0x815f758, 
    myKey=@0xb56c9158, newVal=@0xb56c9154) at mythcontext.cpp:1768
#3  0xb6c19012 in MythContext::readyRead (this=0x815f758, sock=0x817d7d0)
    at mythcontext.cpp:3241
#4  0xb6c62252 in MythSocket::readyReadThread () at mythsocket.cpp:849
#5  0xb5e2146b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6  0xb5c826de in clone () from /lib/tls/i686/cmov/libc.so.6

Version Information:

Source code version : 15201M SVN branch : trunk Library API version : 0.21.20071211-1 Network Protocol Version: 36 Options compiled in:

linux debug using_oss using_alsa using_backend using_dbox2 using_dvb using_frontend using_iptv using_ivtv using_joystick_menu using_lirc using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_opengl using_live

[Nigel]

These do both look like the same problem (UPnP crashes about 25% of the time), but without a gdb trace of the Damian's one, I am not sure. Looks similar to #4243

[anonymous]

It looks like it is happening the same with mythwelcome and mythtv-setup since they crash in the very same way mythfilldatabase does. Mythbackend and mythfrontend do not crash on startup like those three apps do.

[Damian O'Sullivan <damian@…>]

Sorry lost track a bit over xmas. Are you looking for a bt from me?

[Anduin Withers]

(In [15283]) References #4346

upnptasknotify.cpp:

• QStringList iteration isn't thread safe, add some locking around this. Also deep copy g_IPAddrList. The problem is that UPnpNotifyTask::Execute is call by the task queue and by the main thread (during SSDP shutdown).

upnp.cpp:

• UPnp::CleanUp? was calling g_pSSDP->DisableNotifications?() and then deleting g_pSSDP. SSDP::~SSDP() already calls DisableNotifications?().

What I didn't do:

There doesn't seem to be a reason for UPnpNotifyTask::m_addressList to be a member, it should probably just be a deep copy in SendNotifyMsg? to a local.

[Nigel]

I am assuming/hoping that this was fixed by [15283] and [15286]

[anonymous]

Looks like it's fixed. Since those revs I've never had any problem with mythtv-setup, mythfrontend or mythwelcome.