After 16233, channel change to new input segfaults backend

[Mark Buechler <Mark.Buechler@…>]

This happens very reliably. Two sets of backtraces and backend logs attached. The backtraces don't make any sense to me.

[Mark Buechler <Mark.Buechler@…>]

Backtrace 1

[Mark Buechler <Mark.Buechler@…>]

Backend 1

[Mark Buechler <Mark.Buechler@…>]

Backtrace 2

[Mark Buechler <Mark.Buechler@…>]

Backend 2

[danielk]

(In [16236]) Refs #4768. Fix some QString usage in SignalMonitorValue.

[Mark Buechler <Mark.Buechler@…>]

Backend 3

[Mark Buechler <Mark.Buechler@…>]

Backtrace 3

[Mark Buechler <Mark.Buechler@…>]

Backend 4

[Mark Buechler <Mark.Buechler@…>]

Backtrace 4

[Mark Buechler <Mark.Buechler@…>]

After more investigation, this issue appears to be a race condition. By adding an extra VERBOSE within mythevent, I'm unable to make it fail. I don't know that valgrind will catch this, but admittedly, I'm not well versed in valgrind.

[Mark Buechler <Mark.Buechler@…>]

Daniel, can we change that QDeepCopy<QStringList> to:

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

extradata << QDeepCopy<QString>(*it);

To be honest, I have no evidence as to why this should work better than the other and it may very well simply be slowing it down just enough to avoid the race.

[danielk]

(In [16247]) Refs #4768. Fixes a small memory leak discovered when looking at channel change to new input segfault.

[danielk]

Mark, I think the problem may actually be somewhere in the overall handling of MythEvents with extradata. There are only 16 instances in the MythTV code where this type of MythEvent is used and the signal monitor dispatches by far the greatest number of these events.

The code you posted just slows down the copy a little, adding a usleep() in there would probably have the same effect.

[danielk]

Hmm, it looks like this is a duplicate of #4168...

[danielk]

not really a duplicate of #4168...

[danielk]

(In [16382]) Refs #4768. Reverts [16233], [16247]. These didn't fix the segfault Mark was seeing and caused segfaults for others..

[danielk]

Moving to 0.22, my stop-gap fixes appear to have just made the problem worse, we need to address the QString is not thread-safe problem with a more comprehensive solution.

[stuartm]

Is this this an issue in current trunk?

[Mark Buechler <Mark.Buechler@…>]

Well, it was an issue with QString/QStringList not being thread safe, I believe. Last I looked, there was a ticket in trunk to come up with a new MString class to work around the issue.

• Mark.

[stuartm]

Duplicate of #5311