Comment 65 for bug 1480877

@Pat

We might want to hotfix this once we come to fully understand it( and I think we're getting close ).

While working with tvoss a fixes to location-services, we realized that by default, the get-all-match.py script only outputs warnings. While reviewing a test run from tvoss, I didn't see any rules at all for posclientd or slpgwd, as he'd fixed the warnings. As I wanted to check whether or not the leak was still there, I realized I needed to specify "--all" with the script.

This revealed a whole other group of processes that also were monitoring AccessPoint signals. I hadn't noticed them when first running the script, as I was just looking at the default warnings output, and these other processes appear to have specified the rules cleanly. It also appears that these processes are also leaking match rules for the AccessPoint signals as well.

In addition to posclientd, and slpgwd ( tvoss has removed the watches for ubuntu-location-servicesd ) the following processes are involved:

 - msyncd ( part of bueto-syncfw )
 - unity8
 - unity8-dash
 - sync-monitor
 - maliit-server

So, when fully maxed out, these too can reach 5k match rules each ( that's 25k for the five of them ). I just verified that they're all north of 1000 match rules on my krillin just now. This explains why after killing the location-service processes, we still were seeing a brief hiccup every time a WiFi scan occurs.

I also noticed that mission-control-5 listed five AccessPoint match rules only, so that while it's listening, it's not leaking...

All of the above processes except mission-control-5 use QtNetworkSession, whereas mission-control-5 uses nm-glib directly.

I've also verified on krillin that AccessPointAdded and Removed signals are being generated when scan occur, and they seem to make sense. One or more of each signals are received, then a PropertiesChanged signal is fired for the AccessPoints property itself, with the changes indicated by the signals now applied. As it appears none of the AcessPoints are ever being removed from these match rules, my guess is that this is a bug in QNetworkSession vs. NM. I've monitored NM and when scanning occurs, APs are continually added/removed. The list can grow or shrink by 3-10 APs at a time. Of course this doesn't absolutely verify that the signals were sent or received.

I'll attach a script which uses dbus-monitor to watch just the signals sent to the Device.Wireless interface, which should result in just monitoring AccessPointAdded/Removed and the associated PropertiesChanged for the AccessPoints property.

Finally, we urgently need to fix the remaining leaks, but we also probably need to have someone determine whether there's any way to get rid of these rules completely. Does maliit-server really need to see 'LastSeen' property changes from individual access points??? Do any of these processes?