[mythtv] Crash in ~DVBChannel()

roger roger at beardandsandals.co.uk
Thu May 18 11:25:47 UTC 2017

On 17/05/17 11:14, Roger James wrote:
> On 16 May 2017 3:17:49 pm Roger James <roger at beardandsandals.co.uk> 
> wrote:
>> On 16 May 2017 12:54:10 pm Roger Siddons <dizygotheca at ntlworld.com> 
>> wrote:
>>> On 15/05/17 17:29, Roger James wrote:
>>>> I
>>>> fixed this in udev and edited the capture cards in myth to use the new
>>>> names. Part of this edit involved changing the driver type on one 
>>>> of the
>>>> existing card definitions from dvb-t to dvb-s, and of course changing
>>>> the device names on all the entries. This all looked great in
>>>> mythtv-setup 5 capture cards 1 satellite and 4 terrestrial. However I
>>>> had neglected to look at the second page of the card details in the 
>>>> edit
>>>> pages.
>>>> What I had actually ended up with in the database was.
>>>> 2 entries pointing at my mono  DVB-S card set up as parent and 
>>>> child, 2
>>>> entries pointing to tuner 1 on my quad card, 2 entries pointing at 
>>>> tuner
>>>> 2, 1 pointing at tuner 3 and 1 pointing at tuner 4.
>>>> I fixed the crash by setting the concurrent recordings stuff back 
>>>> to 1.
>>>> But I think are more robust fix is needed.
>>> I don't follow the gory details but isn't this because you edited the
>>> cards in mythtv-setup ?
>>> That's a 'known' issue, although I don't recall seeing a ticket for it.
>>> Edits lead to a corrupted database and standard advice is to always
>>> "Delete All Cards on All Hosts" and start afresh. Can you still 
>>> crash it
>>> that way ?
>>> AFAIK it's never been fixed because;
>>> 1. Few people understand that area
>>> 2. The UI settings are due to be replaced by the
>>> origin/devel/mythui/settings at some point. Maybe that will fix edits.
>>> 3. mythtv-setup was planned to be replaced by "some other solution"
>>> years ago...
>> Hi,
>> The short answer is yes, but the long answer is no. The current code 
>> will
>> crash if the DVBChannel destructor is called when the "key" is not in 
>> the
>> "map". At the minimum the code needs to be changed to not crash but 
>> log an
>> error instead. What I am seeing that the inputid in the parent TVRec 
>> object
>> is being set to zero by "something". That means the wrong key is being
>> looked up. This should not be happening. I am struggling to find the
>> circumstances and the "something" that does it. I have not managed to 
>> catch
>> it with a hardware watchpoint in the debugger.
>> Roger
> I am fairly certain now that this is related to running the backend 
> via systemd and having idle shutdown enabled. The example systemd unit 
> file on the wiki allows systemd to shut down the database service 
> before shutting down systemd. Depending on timing this can cause some 
> pretty strange things to happen.
> Roger

I have updated the systemd page in the mythtv wiki with an example that 
stops the database being shut down before the backend is. It also logs 
stderr to the systemd journal and runs mythbackend with the core 
resource limit set to infinity (N.B. this setting is further constrained 
by the rlimit of whatever user id the backend is set to up to use, in 
this case "mythtv").

Also here is a patch to dvbchannel.cpp to make it more robust to the 
database going away.

<     QString key_base = key;
<     DVBChannel *master = NULL;
<     // If the database has gone away the key string may be incorrect
<     if ((!master_map.contains(key)) || (master_map[key].isEmpty()))
<           return;
<     master = static_cast<DVBChannel*>(master_map[key].front());
>     DVBChannel *master = static_cast<DVBChannel*>(master_map[key].front());
>     {
>     }



More information about the mythtv-dev mailing list