Opened 13 years ago
Closed 12 years ago
#9868 closed Bug Report - Hang/Deadlock (Fixed)
Hang in Live TV channel change
Reported by: | 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)
Change History (14)
Changed 13 years ago by
Attachment: | mfechannelchangehang.log added |
---|
mythfrontend -v channel,playback
Changed 13 years ago by
Attachment: | mythmbechannelchangehang.zip added |
---|
mythbackend -v file,channel,record (zipped due to size)
comment:1 Changed 13 years ago by
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
Attachment: | mythfront.bt added |
---|
comment:2 Changed 13 years ago by
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
Attachment: | mythlive.patch added |
---|
Patch to handle death of an embedded player.
comment:3 Changed 12 years ago by
Owner: | changed from Janne Grunau to markk |
---|---|
Status: | new → assigned |
comment:4 Changed 12 years ago by
Owner: | markk deleted |
---|
comment:5 Changed 12 years ago by
Milestone: | unknown → 0.25 |
---|---|
Owner: | set to danielk |
Status: | assigned → accepted |
comment:6 Changed 12 years ago by
Status: | accepted → infoneeded |
---|
Has this been fixed in trunk by the recent commits?
comment:7 Changed 12 years ago by
Resolution: | → Fixed |
---|---|
Status: | infoneeded → closed |
I believe this issue is fixed in master. Please ping if you can reproduce in master.
gdb backtrace on mfe