[mythtv-users] mythfrontend/mythwelcome locking up after prolonged use
mythtv at sky.com
Sat Feb 20 18:20:12 UTC 2010
Ian Clark wrote:
> On 19 February 2010 18:55, Paul Harrison <mythtv at sky.com
> <mailto:mythtv at sky.com>> wrote:
> OK, thanks for taking the time to produce the log. It does look like a
> problem with the new MythSignalingTimer leaking memory when the main
> thread in mythwelcome isn't running. I think it's because the
> MythSignalingTimer is run in it's own thread and so continues to emit
> signals even when the main thread isn't running and so the signals
> get queued up waiting for the main thread to resume.
> That's no problem, thanks for debugging it for me.
> So the fix looks like it would be to stop the MythSignalingTimer in
> MythMainWindow when mythsystem() is used to start an external process
> and resume it again when it finishes. I'll have a look at trying this
> over the weekend.
> FWIW, I popped a changeEvent handler on MythMainWindow and did
> 'd->drawTimer->stop()' on activation loss, which seems to have cured
> the problem for mythwelcome (although not for mythfrontend launching
> xbmc, but I suspect that's due to the dirtyness of my patch.) This
> does however solve the main problem of not being able to do anything
> with the remote that I was having. (ssh to reboot all the time is
> tedious.) so I'm happy.
> Thanks again for the clear and concise fix. :)
I've just committed a fix for this problem to trunk. It should be
generic enough to fix all cases where either MythWelcome or MythFrontend
runs external programs so long as they use myth_system() to start the
process which they do in all the cases that I know of.
More information about the mythtv-users