touch-packages team mailing list archive

[Tony Espy <1480877@xxxxxxxxxxxxxxxxxx>]

@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?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to indicator-network in
Ubuntu.
https://bugs.launchpad.net/bugs/1480877

Title:
  Access points' "PropertiesChanged" dbus signals freeze UI on mobile
  devices

Status in Canonical System Image:
  Confirmed
Status in indicator-network package in Ubuntu:
  Incomplete
Status in network-manager package in Ubuntu:
  Incomplete
Status in location-service package in Ubuntu RTM:
  New
Status in network-manager package in Ubuntu RTM:
  Incomplete

Bug description:
  Krillin, rc-proposed, r83

  
  DESCRIPTION:
  I've been trying to track down the cause of the occasional UI freezes on my Krillin device, and I noticed that whenever the UI freezes for 2-4 seconds, I get a burst of "PropertiesChanged" signals in dbus-monitor

  Here's a log of what's shown in dbus-monitor:
  http://pastebin.ubuntu.com/11992322/

  I'd guess the problem is in the code that actually catches the signals
  and acts accordingly.

  HOW TO REPRODUCE: 
  1) Move to a place where many wifi hotspots are available
  2) Connect the device via USB and run "phablet-shell" and then "dbus-monitor"
  3) Use the device while keeping an eye on dbus-monitor output

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1480877/+subscriptions