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

[Ian Clark]

On 20 February 2010 18:20, Paul Harrison <mythtv at sky.com> wrote:

> 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.
>

Cheers for that, I was just atttempting another half assed fix, as my first
attempt didn't work as expected, but I shall just svn up now.

Thanks again. :)

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100220/1627c188/attachment.htm>