[mythtv-users] mythfrontend/mythwelcome locking up after prolonged use

[Paul Harrison]

Ian Clark wrote:
>
>
> On 19 February 2010 18:55, Paul Harrison <mythtv at sky.com
> <mailto:mythtv at sky.com>> wrote:
>
>     [snip]
>
>     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
>     just
>     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. :)
>
> Cheers,
>
> Ian


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.

Paul H.