Do not access to timer after we call the associated function.
Some of these callbacks can call spice_timer_remove making the pointer
pointing to freed data.
This happen for instance when the client is disconnecting.
This does not cause memory corruption on current allocator
implementations as all freeing/accessing happen on a single thread quite
closely and allocators use different pools for different thread.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
static void _spice_timer_set(SpiceTimer *timer, uint32_t ms, uint32_t now)
The _spice_timer_set() function takes a 32-bit integer for the "now" value.
The now value passed in however, can exceed 2^32 (it's in ms and derived
from CLOCK_MONOTONIC, which will wrap around a 32-bit integer in around 46
days).
If the now value passed in exceeds 2^32, this will mean timers are inserted
into the active list with expiry values before the current time, they will
immediately trigger, and (if they don't make themselves inactive) be
reinserted still before the current time.
This leads to an infinite loop in spice_timer_queue_cb().
https://bugzilla.redhat.com/show_bug.cgi?id=1072700
For channels that don't run as part of the main loop, we use
spice_timer_queue, while for the other channels we use
qemu timers support. The callbacks for setting timers are supplied to
red_channel via SpiceCoreInterface, and their behavior should be
consistent. qemu timers are called only once per each call to
timer_start. This patch assigns the same behaviour to spice_timer_queue.
