Opened 5 years ago
Closed 5 years ago
#11194 closed Bug Report - General (Fixed)
Mythfrontend hangs when exiting
Reported by: | bob.havlin@… | Owned by: | jyavenard |
---|---|---|---|
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 5 years ago by bob.havlin@…
comment:2 Changed 5 years ago by danielk
- Status changed from new to 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.
Changed 5 years ago by bob.havlin@…
bt of mythfrontend exit hang
comment:3 follow-up: ↓ 4 Changed 5 years ago by pyther@…
I am also affected by this issue. I would be willing to provide any information necessary.
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 17 Changed 5 years ago by 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.
comment:5 Changed 5 years ago by borgeh@…
Same problem here. Kubuntu 12.10, 0.26 patches, kernel 3.5 x64. Honk if you want me to log something.
comment:6 Changed 5 years ago by lmaendle@…
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 5 years ago by borgeh@…
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 5 years ago by danielk
Bob Havlin, we need a full backtrace. The one you grabbed is of only a single thread.
comment:9 in reply to: ↑ 8 Changed 5 years ago by bob.havlin@…
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 5 years ago by danielk
Possible fix
Changed 5 years ago by danielk
updated
Changed 5 years ago by George Nassas <gnassas@…>
a full backtrace of a non-patched FE
comment:10 Changed 5 years ago by George Nassas <gnassas@…>
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 5 years ago by George Nassas <gnassas@…>
a hung FE with the v2 patch applied
comment:11 follow-up: ↓ 12 Changed 5 years ago by George Nassas <gnassas@…>
Hi, I got an FE exit hang even though I have the patch applied.
Changed 5 years ago by lmaendle@…
This patch corrects the problem for me.
comment:12 in reply to: ↑ 11 Changed 5 years ago by lmaendle@…
The above attached patch (mythtv_airplay.patch) corrects the problem for me.
Changed 5 years ago by deadletterfile@…
gnu debugger from mythfrontend
comment:13 Changed 5 years ago by deadletterfile@…
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 5 years ago by danielk
- Milestone set to 0.26.1
- Status changed from infoneeded_new to new
comment:15 Changed 5 years ago by danielk
- Owner set to danielk
- Status changed from new to assigned
comment:16 Changed 5 years ago by bob.havlin@…
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.
Changed 5 years ago by bob.havlin@…
mythfronted -loglevel debug logfile
comment:17 in reply to: ↑ 4 Changed 5 years ago by anonymous@…
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 5 years ago by jyavenard
- Owner changed from danielk to jyavenard
- Status changed from assigned to accepted
comment:19 Changed 5 years ago by dekarl
- Component changed from MythTV - General to MythTV - Airplay
comment:20 Changed 5 years ago by danielk
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 5 years ago by jyavenard
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 5 years ago by Jean-Yves Avenard <jyavenard@…>
- Resolution set to fixed
- Status changed from accepted to closed
comment:23 Changed 5 years ago by jyavenard
- Resolution fixed deleted
- Status changed from closed to new
oops..
wrong ticket
comment:24 Changed 5 years ago by jyavenard
- Resolution set to Fixed
- Status changed from new to closed
This was fixed in e1773c2cf7bb38dc08ffa3a134602c8b173f6c9d
Tried attaching the file, but Trac claims it is spam.