1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00

Work around a timer leak with GTK 2.4.22 on openSUSE 13.1.

Mihkel Ader reports that on that system, timers apparently aren't
getting auto-destroyed when timer_trigger returns FALSE, so the change
in r10181 has caused GTK PuTTY to gradually allocate more and more
timers and consume more and more CPU as they all keep firing.

As far as I can see, this must surely be a bug in GTK 2 (the docs say
that timers _are_ auto-destroyed when their callback returns false),
and it doesn't seem to happen for me with GTK 2.4.23 on Ubuntu 14.04.
However, I'll try to work around it by _explicitly_ destroying each
old timer before we zero out the variable containing its id.

[originally from svn r10202]
[r10181 == e4c4bd2092]
This commit is contained in:
Simon Tatham 2014-07-08 22:22:12 +00:00
parent 7f17b44b0e
commit 4647eded7c

View File

@ -1477,12 +1477,13 @@ static gint timer_trigger(gpointer data)
long ticks; long ticks;
/* /*
* The timer we last scheduled via gtk_timeout_add has just * Remove the timer we got here on; if we need another one, we'll
* triggered, and since we're about to return FALSE, it won't be * set it up below.
* resumed. So zero out its id, in case we don't overwrite it in
* the next loop.
*/ */
timer_id = 0; if (timer_id) {
gtk_timeout_remove(timer_id);
timer_id = 0;
}
if (run_timers(now, &next)) { if (run_timers(now, &next)) {
then = now; then = now;
@ -1496,8 +1497,9 @@ static gint timer_trigger(gpointer data)
} }
/* /*
* Never let a timer resume. If we need another one, we've * Returning FALSE means 'don't call this timer again', which
* asked for it explicitly above. * _should_ be redundant given that we removed it above, but just
* in case, return FALSE anyway.
*/ */
return FALSE; return FALSE;
} }