Mailing List Archive

Crash in ~DVBChannel()
I recently put an old tt budget DVB-S card into my main system to do some
testing. This system already a quad tuner dvb-t card in it. Adding the new
card meant I immediately ran into persistent naming problems. 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.


The current code looks like this. It crashes because either the map does
not contain the key or it does but the list for that key is empty.


DVBChannel::~DVBChannel()
{
// set a new master if there are other instances and we're the master
// whether we are the master or not remove us from the map.
master_map_lock.lockForWrite();

QString key = CardUtil::GetDeviceName(DVB_DEV_FRONTEND, device);

if (m_pParent)
key += QString(":%1") .arg(CardUtil::GetSourceID(m_pParent->GetInputId()));

DVBChannel *master = static_cast<DVBChannel*>(master_map[key].front());

I stuck some diagnostics in and I got this.

~DVBChannel(0x61500000cf80)
~DVBChannel(0x61500000cf80) key /dev/dvb/adapter_tt1/frontend0
~DVBChannel(0x61500000cf80) master_map does not contain key
/dev/dvb/adapter_tt1/frontend0
~DVBChannel(0x61500000cf80) removing all instances of this from master_map

~DVBChannel(0x61500000cd00)
~DVBChannel(0x61500000cd00) key /dev/dvb/adapter_tt1/frontend0
~DVBChannel(0x61500000cd00) master_map for /dev/dvb/adapter_tt1/frontend0:0
is empty
~DVBChannel(0x61500000cd00) removing all instances of this from master_map

mythbackend.service: Main process exited, code=dumped, status=11/SEGV
Stopped MythTV backend service.
mythbackend.service: Unit entered failed state.
mythbackend.service: Failed with result 'core-dump'.

I had put the line that initially shows just the key a bit too early in the
function. The actual key is shown in the following lines.

Comments anyone?

Roger



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Crash in ~DVBChannel() [ In reply to ]
On 15 May 2017 5:48:58 pm Roger James <roger@beardandsandals.co.uk> wrote:

> I recently put an old tt budget DVB-S card into my main system to do some
> testing. This system already a quad tuner dvb-t card in it. Adding the new
> card meant I immediately ran into persistent naming problems. 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.
>
>
> The current code looks like this. It crashes because either the map does
> not contain the key or it does but the list for that key is empty.
>
>
> DVBChannel::~DVBChannel()
> {
> // set a new master if there are other instances and we're the master
> // whether we are the master or not remove us from the map.
> master_map_lock.lockForWrite();
>
> QString key = CardUtil::GetDeviceName(DVB_DEV_FRONTEND, device);
>
> if (m_pParent)
> key += QString(":%1") .arg(CardUtil::GetSourceID(m_pParent->GetInputId()));
>
> DVBChannel *master = static_cast<DVBChannel*>(master_map[key].front());
>
> I stuck some diagnostics in and I got this.
>
> ~DVBChannel(0x61500000cf80)
> ~DVBChannel(0x61500000cf80) key /dev/dvb/adapter_tt1/frontend0
> ~DVBChannel(0x61500000cf80) master_map does not contain key
> /dev/dvb/adapter_tt1/frontend0
> ~DVBChannel(0x61500000cf80) removing all instances of this from master_map
>
> ~DVBChannel(0x61500000cd00)
> ~DVBChannel(0x61500000cd00) key /dev/dvb/adapter_tt1/frontend0
> ~DVBChannel(0x61500000cd00) master_map for /dev/dvb/adapter_tt1/frontend0:0
> is empty
> ~DVBChannel(0x61500000cd00) removing all instances of this from master_map
>
> mythbackend.service: Main process exited, code=dumped, status=11/SEGV
> Stopped MythTV backend service.
> mythbackend.service: Unit entered failed state.
> mythbackend.service: Failed with result 'core-dump'.
>
> I had put the line that initially shows just the key a bit too early in the
> function. The actual key is shown in the following lines.
>
> Comments anyone?
>
> Roger
>
>
I forgot to add that I also changed the logic a bit to ensure that master
was set to NULL if a valid value was not available. That's why the log
shows it crashing on the second TVrec.

R.



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Crash in ~DVBChannel() [ In reply to ]
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...
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Crash in ~DVBChannel() [ In reply to ]
On 16 May 2017 12:54:10 pm Roger Siddons <dizygotheca@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...
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

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


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Crash in ~DVBChannel() [ In reply to ]
On 16 May 2017 3:17:49 pm Roger James <roger@beardandsandals.co.uk> wrote:

> On 16 May 2017 12:54:10 pm Roger Siddons <dizygotheca@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...
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
> 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


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Crash in ~DVBChannel() [ In reply to ]
On 17/05/17 11:14, Roger James wrote:
> On 16 May 2017 3:17:49 pm Roger James <roger@beardandsandals.co.uk>
> wrote:
>
>> On 16 May 2017 12:54:10 pm Roger Siddons <dizygotheca@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.

91d90
<
115d113
< QString key_base = key;
119,127c117
<
< 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());
137a128
> {
139c130
<
---
> }

Cheers

Roger
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org