Opened 12 years ago
Closed 11 years ago
#11194 closed Bug Report - General (Fixed)
Mythfrontend hangs when exiting
Reported by: | Owned by: | JYA | |
---|---|---|---|
Priority: | minor | Milestone: | 0.26.1 |
Component: | MythTV - Airplay | Version: | 0.26-fixes |
Severity: | medium | Keywords: | mythfrontend |
Cc: | Ticket locked: | no |
Description
When exiting mythfrontend, the application hangs.
If I press Ctrl-c twice from the command line, it eventually quits. Looks like the hang begins with "Bonjour: De-registering service" but nothing informative comes from the "mythfrontend -v all" option.
Attachments (8)
Change History (32)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
Status: | new → infoneeded_new |
---|
Please grab a backtrace after the last debug message is printed. The TicketHowTo has links describing how to grab a backtrace. Then attach the backtrace here so we can analyze it.
FYI In the spam filter catches you out then compressing the log will allow you to bypass the filter but in this case the log is unlikely to tell us much.
comment:3 follow-up: 4 Changed 12 years ago by
I am also affected by this issue. I would be willing to provide any information necessary.
comment:4 follow-up: 17 Changed 12 years ago by
Replying to pyther@…:
I am also affected by this issue. I would be willing to provide any information necessary.
+1. openSUSE 12.2 x64; mythtv 0.25 works fine; removed all 0.25 traces prior to 0.26. myth-setup also hangs.
comment:5 Changed 12 years ago by
Same problem here. Kubuntu 12.10, 0.26 patches, kernel 3.5 x64. Honk if you want me to log something.
comment:6 Changed 12 years ago by
The effect happens only on pure frontend machines. Some debugging reveals, that in mythairplayserver.cpp the function call on line 355 (gMythAirplayServerThread->wait()) does not return. It seems, that the function call in the previous line (gMythAirplayServerThread->exit()) has no effect.
comment:7 Changed 12 years ago by
K 12.10 user 2 above here again. I run both backend and frontend on the same computer, but still got the effect. Now I cannot reproduce it, but I will get back here if it shows up again. It would be strange if 0.26 patches somehow fixed this during the last day...
comment:8 follow-up: 9 Changed 12 years ago by
Bob Havlin, we need a full backtrace. The one you grabbed is of only a single thread.
comment:9 Changed 12 years ago by
Replying to danielk:
we need a full backtrace. The one you grabbed is of only a single thread.
Unfortunately/fortunately, I cannot get it to hang anymore. I did a clean reinstall of mythbuntu over the weekend and I think that may be the reason.
Not sure if it is related, but airplay was not working and after my clean install airplay works.
I'll keep trying to see if I can get it to hang, but previously it would hang every time I exited.
Changed 12 years ago by
Attachment: | hung.FE.v0.27-pre2-307-gc79ff7e.txt added |
---|
a full backtrace of a non-patched FE
comment:10 Changed 12 years ago by
I didn't notice the patches until just now but I'll update my system and see if the hang happens again. In the meantime the full bt may verify if the patch is headed in the right direction.
Changed 12 years ago by
Attachment: | hung.FE.v0.27-pre2-307-gc79ff7e-w-11194-v2-patch.txt added |
---|
a hung FE with the v2 patch applied
comment:11 follow-up: 12 Changed 12 years ago by
Hi, I got an FE exit hang even though I have the patch applied.
Changed 12 years ago by
Attachment: | mythtv_airplay.patch added |
---|
This patch corrects the problem for me.
comment:12 Changed 12 years ago by
The above attached patch (mythtv_airplay.patch) corrects the problem for me.
comment:13 Changed 12 years ago by
My approach was brutish. I commented out line 314 in mythairplayserver.cpp
gMythAirplayServerThread = new MThread("AirplayServer?");
to prevent the airplay server from being created.
For me the only response to a mythfrontend hang was [Ctrl][Alt][F3] from which I could log in and kill mythfrontend. [Alt][Tab] nor the mouse seemed to work. RoyBoy626
comment:14 Changed 12 years ago by
Milestone: | → 0.26.1 |
---|---|
Status: | infoneeded_new → new |
comment:15 Changed 12 years ago by
Owner: | set to danielk |
---|---|
Status: | new → assigned |
comment:16 Changed 12 years ago by
The problem is back after upgrading to ubuntu-12.10 and the most recent compile of mythtv:
mythfrontend --version Please attach all output as a file in bug reports. MythTV Version : v0.26.0-93-ga1b9b1f MythTV Branch : fixes/0.26 Network Protocol : 75 Library API : 0.26.20130112-1 QT Version : 4.8.3 Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2
See attached logfile.
comment:17 Changed 12 years ago by
Replying to anonymous@…:
Replying to pyther@…:
I am also affected by this issue. I would be willing to provide any information necessary.
+1. openSUSE 12.2 x64; mythtv 0.25 works fine; removed all 0.25 traces prior to 0.26. myth-setup also hangs.
Disabling AirPlay? under FE Setup/General? solves the FE hanging but myth-setup still hangs.
comment:18 Changed 12 years ago by
Owner: | changed from danielk to JYA |
---|---|
Status: | assigned → accepted |
comment:19 Changed 12 years ago by
Component: | MythTV - General → MythTV - Airplay |
---|
comment:20 Changed 12 years ago by
jya, I think the problem might be deeper than just changing how m_bonjour is deleted. I only looked at this a little bit but I think this might suffer from that QXXXSocket issue I discussed with you. i.e. where all the sockets are created in the same thread and all the socket handling ends up being done in that one thread. If so there are two workarounds: 1/ just pass a socket file descriptor instead of a QTcpSocket to the handler thread and create the QTcpSocket in the right thread or 2/ you can reassign the thread a QObject belongs to using http://qt-project.org/doc/qt-4.8/qobject.html#moveToThread.
#1 has implications for Qt5 which changes the socket descriptor type from int to qintptr, but if you get it to work on Qt4.x I can easily make it Qt5 compatible since I have the build environment set up.
Anyway, I only did a little of bit of debugging before deciding this was a rabbit hole I didn't have time for at the time. I did find that the way to reproduce this was to run bonjour in an environment where it could never start up properly (I don't remember the details.)
comment:21 Changed 12 years ago by
daniel, in the case of AirPlay? video, the QXXSocket is created in the main thread, and deleted in the main thread
But I'll look into it further...
comment:22 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
comment:24 Changed 11 years ago by
Resolution: | → Fixed |
---|---|
Status: | new → closed |
This was fixed in e1773c2cf7bb38dc08ffa3a134602c8b173f6c9d
Tried attaching the file, but Trac claims it is spam.