Unknown problem with socket communications causes segfault of backends

[Mark.Buechler@…]

I'm seeing random segfaults on average of once daily of both my backends so I enabled core dumps. I had originally thought to run mythbackend under gdb until I could catch one of these but the problem is gdb exits and kills mythbackend 1 out of every 5 channel changes on average for some reason. This is the only way I can get a backtrace of the problem. I have a total of 6 backtraces from my two myth backends all relating to inter-backend communications I believe.

[Mark.Buechler@…]

Backtrace 1 of my then slave backend corbin3

[Mark.Buechler@…]

Backtrace 2 of my then slave backend corbin3

[Mark.Buechler@…]

Backtrace 3 of my then slave backend corbin3

[Mark.Buechler@…]

Backtrace 4 of my then slave backend corbin3

[Mark.Buechler@…]

Backtrace 1 of my CURRENT slave backend corbin2

[Mark.Buechler@…]

Backtrace 2 of my CURRENT slave backend corbin2

[Mark.Buechler@…]

Let me just add one other note. The first 4 backtraces were on my backend corbin3 which was, at the time, a slave backend. The last two backtraces are from my current slave backend, corbin2. Between backtraces 4 and 5 I switched roles of my backends in n attempt to track down this issue. This is running svn 12173.

[jwestfall]

I have been able to reproduce that crash in MainServer::customEvent() about 50% of the time with the following.

remote frontend talking to master backend with 2xhdhr and 2xfirewire tuners. Start livetv (hdhr tuner), goto epg guide and select a channel that is only supported by the firewire tuner and tune it. It will crash 50% of the time at that point.

[Mark.Buechler@…]

Backtrace 5 of my then slave backend corbin3

[Mark.Buechler@…]

Backtrace 5 of my then slave backend corbin2

[Mark.Buechler@…]

Added two more backtraces.. bt5 on the master backend and 4 minutes later bt5a on my slave.

[martin@…]

Backtrace of mythbackend crash on SUSE Linux 10.1 32-bit (compiled with --compile-type=debug)

[jwestfall]

attached mythevent.diff to the ticket, see if this fixes the customEvent crash in the backend.

[Mark.Buechler@…]

BT after patch applied

[Mark.Buechler@…]

That patch didn't seem to help though it did produce a different backtrace which may give more clues as to what's going on. Bt attached.

[Mark.Buechler@…]

With some debugging, below shows the last messages passing through customEvent() before the last segfault I captured in Mainserver::customEvent():

2007-01-11 11:44:30.368 Finished recording Munich: channel 1502 2007-01-11 11:44:30.374 ---------> MythEvent?(): empty 2007-01-11 11:44:30.387 ---------> MythEvent?(): Message: RECORDING_LIST_CHANGE 2007-01-11 11:44:30.392 ---------> MythEvent?(): empty 2007-01-11 11:44:30.535 ---------> MythEvent?(): Message: RECORDING_LIST_CHANGE 2007-01-11 11:44:30.541 ---------> MythEvent?(): empty 2007-01-11 11:44:31.959 ---------> MythEvent?(): Message: QUERY_NEXT_LIVETV_DIR 5 2007-01-11 11:44:31.964 ---------> MythEvent?(): empty 2007-01-11 11:44:32.042 ---------> MythEvent?(): Message: RECORDING_LIST_CHANGE 2007-01-11 11:44:32.049 ---------> MythEvent?(): empty 2007-01-11 11:44:32.073 ---------> MythEvent?(): Message: LIVETV_CHAIN UPDATE live-pc4-2007-01-11T09:08:54 2007-01-11 11:44:32.079 ---------> MythEvent?(): empty 2007-01-11 11:44:33.232 ---------> MythEvent?(): Message: SIGNAL 5

The very next line would have shown each entry in extradata or "empty", but this is where the segfault occured instead in the area where I attempted to spit out the entries:

for ( QStringList::Iterator it = _list.begin(); it != _list.end(); ++it )

VERBOSE(VB_IMPORTANT, QString("---------> MythEvent?(): %1").arg(*it));

[danielk]

We're no longer fixing 0.20 bugs.