gclue-wifi: Cancel existing scan timeout before scheduling another

Since the state of wpa_supplicant is out of our control, `ScanDone`
signals could be received at any time. Previously, we’d schedule another
scan timeout for each one, without cancelling any previously-scheduled
timeout. This could result in multiple timeouts in flight, but with the
`GClueWifi` code only holding an ID for the most recent one.

If the `GClueWifi` object was then destroyed, it was possible for the
timeout callbacks to still be invoked, with a dangling pointer to the
`GClueWifi`, resulting in a crash.

Fix that by cancelling any in-flight timeout before scheduling another.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #126

1 files changed, 9 insertions, 0 deletions

diff --git a/src/gclue-wifi.c b/src/gclue-wifi.c
index d64e8da..0bb166c 100644
--- a/src/gclue-wifi.c
+++ b/src/gclue-wifi.c
@@ -481,6 +481,15 @@ on_scan_done (WPAInterface *object,
                 gclue_web_source_refresh (GCLUE_WEB_SOURCE (wifi));
         }
 
+        /* If there was another scan already scheduled, cancel that and
+         * re-schedule. Regardless of our internal book-keeping, this can happen
+         * if wpa_supplicant emits the `ScanDone` signal due to a scan being
+         * initiated by another client. */
+        if (priv->scan_timeout != 0) {
+                g_source_remove (priv->scan_timeout);
+                priv->scan_timeout = 0;
+        }
+
         /* With high-enough accuracy requests, we need to scan more often since
          * user's location can change quickly. With low accuracy, we don't since
          * we wouldn't want to drain power unnecessarily.