Opened 13 years ago

Closed 12 years ago

#9868 closed Bug Report - Hang/Deadlock (Fixed)

Hang in Live TV channel change

Reported by: skd5aner <skd5aner@…> Owned by: danielk
Priority: minor Milestone: 0.25
Component: MythTV - Video Playback Version: 0.24-fixes
Severity: medium Keywords: Live TV, channel changing, hang
Cc: Ticket locked: no

Description

mythfrontend will sometimes hang while attempting a channel change within live tv. While I'm not exactly sure how to replicate this on demand, it is something that occurs frequently enough that anytime I have guests over who use Live TV, I inevitably have to restart the frontend due to this issue.

Simply, while watching live tv, when attempting to switch to another channel, the screen will turn black (if changing from the guide, you'll see the theme background image for several seconds before turning black), and become unresponsive to any input via lirc, keyboard, or otherwise. No dialog boxes or OSD information is displayed. The OS will respond to keyboard commands such as alt-tab in which I can bring focus to a console and kill the frontend that way. This occurs "randomly", at least from what I can tell as successful channel changes occur about ~85-90% of the time.

I've attached a backtrace (compiled source in "profile"), a mythfrontend -v playback,channel, and a master mythbackend -v file,channel,record. I also have a slave mythbackend log as well, but I do not think it's necessary to attach yet since none of the tuners attached to it were used while attempting to watch Live TV. If asked, I can attach it upon request.

If there are any additional details needed, please let me know and I'll do my best to provide/test whatever I can.

Thank you in advance!

Attachments (7)

gdb.txt (41.4 KB) - added by skd5aner <skd5aner@…> 13 years ago.
gdb backtrace on mfe
mfechannelchangehang.log (214.8 KB) - added by skd5aner <skd5aner@…> 13 years ago.
mythfrontend -v channel,playback
mythmbechannelchangehang.zip (159.6 KB) - added by skd5aner <skd5aner@…> 13 years ago.
mythbackend -v file,channel,record (zipped due to size)
version.txt (685 bytes) - added by skd5aner <skd5aner@…> 13 years ago.
--version details
mythfront.bt (14.1 KB) - added by Ian Dall <ian@…> 13 years ago.
mythfront.log (148.3 KB) - added by Ian Dall <ian@…> 13 years ago.
mythfrontend -v general,playback
mythlive.patch (4.1 KB) - added by Ian Dall <ian@…> 13 years ago.
Patch to handle death of an embedded player.

Download all attachments as: .zip

Change History (14)

Changed 13 years ago by skd5aner <skd5aner@…>

Attachment: gdb.txt added

gdb backtrace on mfe

Changed 13 years ago by skd5aner <skd5aner@…>

Attachment: mfechannelchangehang.log added

mythfrontend -v channel,playback

Changed 13 years ago by skd5aner <skd5aner@…>

mythbackend -v file,channel,record (zipped due to size)

Changed 13 years ago by skd5aner <skd5aner@…>

Attachment: version.txt added

--version details

comment:1 Changed 13 years ago by Ian Dall <ian@…>

I am seeing what looks like the same bug still in v0.25pre-2771-g3378703. I get two slightly different manifestations. One is a SIGSEGV and the other is a "hang" with the guide screen showing but unpopulated.

When I don't get a SIGSEGV I get the messages:

2011-08-03 21:27:46.554236 E  TV: LiveTV not successfully started
2011-08-03 21:27:46.554413 I  TV: Main UI disabled.
2011-08-03 21:27:46.727464 I  TV: Entering main playback loop.
2011-08-03 21:28:32.007203 I  TV: Exiting main playback loop.
QMutex::lock: mutex lock failure: Invalid argument

My theory is that both behaviours have the same cause because when I catch the SIGSEGV with gdb, the screen shows the guide in much the same state at for the "Invalid argument" case. Both cases have similar stack traces (like the gdb.txt attachment).Probably there is some uninitialised location, and depending on exactly what rubbish is in the location causes either a SIGSEGV or other undefined behaviour.

GuideGrid::updateChannels calls m_player->GetPlayerReadLock?. It seems that since the LiveTV was not successfully started, maybe there is no valid mutex to lock. Certainly, after the SIGSEGV, gdb shows

(gdb) frame 0
#0  0x02e1d90a in QMutex::lock (this=0xa071c40) at thread/qmutex.cpp:151
(gdb) print d
$9 = (QMutexPrivate *) 0x0

so attempting to access d->recursive will cause the fault.

I'm attaching a backtrace for the SIGSEGV case.

Changed 13 years ago by Ian Dall <ian@…>

Attachment: mythfront.bt added

Changed 13 years ago by Ian Dall <ian@…>

Attachment: mythfront.log added

mythfrontend -v general,playback

comment:2 Changed 13 years ago by Ian Dall <ian@…>

I can confirm the following behaviour [v0.25pre-2918-g97e478d-dirty] (which is dirty because of extra diagnostic messages):

  • LiveTV player timesout. This could be a "bad" channel, no signal, or bug in the backend causing it to be unresponsive.
  • The TV object's destructor is called.
  • The GuideGrid? object still has a non-null pointer (m_player) to the now non existent TV object.
  • Chaos ensues as the m_player pointer is used to access various members of the defunct TV object.

This is consistent with the previously attached gdb.txt. However, I think this only explains issues when "Start in Guide" is used.

I'm attaching a patch. It adds a signal/slot pair so that GuideGrid? can be notified that m_player is no longer valid. This seems to fix the hang and SIGSEGVs but GuideGrid? is not longer in Live TV "mode" when it doesn't have a player. Really on death of a player it should exit the GuideGrid? menu. Or perhaps better still, switch to a special player which displays a "Not Responding" jpeg.

Changed 13 years ago by Ian Dall <ian@…>

Attachment: mythlive.patch added

Patch to handle death of an embedded player.

comment:3 Changed 12 years ago by beirdo

Owner: changed from Janne Grunau to markk
Status: newassigned

comment:4 Changed 12 years ago by markk

Owner: markk deleted

comment:5 Changed 12 years ago by danielk

Milestone: unknown0.25
Owner: set to danielk
Status: assignedaccepted

comment:6 Changed 12 years ago by danielk

Status: acceptedinfoneeded

Has this been fixed in trunk by the recent commits?

comment:7 Changed 12 years ago by danielk

Resolution: Fixed
Status: infoneededclosed

I believe this issue is fixed in master. Please ping if you can reproduce in master.

Note: See TracTickets for help on using tickets.