sugar shell leaks presence service info

[tomeu]

Each buddy that appears and disappears leaks 20KB of memory.

[tomeu]

This patch will release the buddies mem for real when they disappear.

[marco]

Looks good to me. It's certainly a bit risky. Let's get it in asap, so that we can test it well.

[mstone]

Fix this please. How did we regress?

[marco]

sugar-0.82.4-1.olpc3

There are other leaks related to buddies appear/disappear. But this one is still good to go in.

[marco]

Approved by me.

[cscott]

sugar 0.82.5-1 added to 8.2 repo; should be in build 760 and later. Please test.

[cscott]

http://mock.laptop.org/gitweb/gitweb.cgi?p=repos;a=commitdiff;h=022716da54a06a498962aa978ca335dd43b1fb95

[mstone]

Tomeu -- you're either going to need to write a test case for this ticket or to test it yourself. Which will it be?

[marco]

Tomeu, I guess the only way to really verify this one is heapy. Can we make it reasonably easy for a QA person to get that data out of heapy? (adding some code to sugar-shell to run heapy and record the results for example). Or at least for a developer not particularly familiar with it

Even if we wrote down the procedure somewhere on the wiki, requiring to patch code seems too much for a testcase, too many things could go wrong.

[mchua]

This is a draft test case using the new memory leak testing howto - I'm not sure if this tests the problem we're looking for. Does it? If so, I'll run. If not, please revise.

|TestCase|

• Get 2 XOs running 8.2-760 (call these XO-1 and XO-2)
• set up XO-1 for memory leak testing
• perform a memory leak test on XO-1 (using another computer to ssh in, as per instructions on the memory leak testing howto page) - the action you should be testing between hp.setref() and hp.heap() is
  • turning on XO-2
  • connecting it to the same network/mesh/AP as XO-1 (so that XO-2 shows up in Neighborhood)
  • turning off XO-2 (so it no longer shows up in Neighborhood)
• look for a 20kb leak

[marco]

Nice work on documenting this :)

[mchua]

Thanks, Marco! Assigning to Frances to test (and close, hopefully!) to see if my test case writing is clear enough to follow.

[frances]

Attempted test case, but was very difficult due to the neighborhood view of the testing XO not accurately representing the XO that should not be on the view anymore (because I disconnected with the network and then shut down and it was still showing an icon!). Until we can solve this stale presence bug, the leak test is difficult to do.

just in case we caught this data: on, off, buddy icon did not fade - 331 objects, 25860 bytes

[frances]

attempted again on 760 and same issue.

caught this data: on, off, buddy icon did not fade - 479 objects, 45352 bytes

[frances]

attempted again in 762 and same thing with the stale presence.

caught this data: on, off, buddy icon did not fade -509 objects, 35244 bytes.

[tomeu]

Yes, if the icon doesn't disappear, it's normal for memory to grow.

[mchua]

Yeah... I don't think we can test this until #7893 (and other presence service bugs, I don't know the situation enough to find the relevant ones from a search - help?) are closed, unless there is another way to force buddies to disappear from Neighborhood view. Should we put the presence service bug(s) as blockers on this one (it doesn't block a fix, but it blocks testing)?

[frances]

attempted again on 767 and had to wait 10 minutes (exactly!) for the icon to disappear from the XO.

Partition of a set of 1339 objects. Total size = 136740 bytes.

Index Count % Size % Cumulative % Kind (class / dict of class)

0 102 8 13056 10 13056 10 str 1 24 2 12480 9 25536 19 dict of sugar.graphics.animator.Animator 2 54 4 12448 9 37984 28 dbus.String 3 64 5 8704 6 46688 34 dict (no owner) 4 16 1 8320 6 55008 40 dict of sugar.graphics.icon._IconBuffer 5 212 16 7632 6 62640 46 types.MethodType 6 4 0 6688 5 69328 51 dict of sugar.graphics.palette.Palette 7 4 0 6688 5 76016 56 dict of view.BuddyMenu.BuddyMenu 8 70 5 4576 3 80592 59 list 9 20 1 4272 3 84864 62 unicode

[frances]

Replying to frances:

attempted again on 767 and had to wait 10 minutes (exactly!) for the icon to disappear from the XO. Partition of a set of 1339 objects. Total size = 136740 bytes. Index Count % Size % Cumulative % Kind (class / dict of class) 0 102 8 13056 10 13056 10 str 1 24 2 12480 9 25536 19 dict of sugar.graphics.animator.Animator 2 54 4 12448 9 37984 28 dbus.String 3 64 5 8704 6 46688 34 dict (no owner) 4 16 1 8320 6 55008 40 dict of sugar.graphics.icon._IconBuffer 5 212 16 7632 6 62640 46 types.MethodType 6 4 0 6688 5 69328 51 dict of sugar.graphics.palette.Palette 7 4 0 6688 5 76016 56 dict of view.BuddyMenu.BuddyMenu 8 70 5 4576 3 80592 59 list 9 20 1 4272 3 84864 62 unicode

let's try that again:

Partition of a set of 1339 objects. Total size = 136740 bytes.

Index Count % Size % Cumulative % Kind (class / dict of class)

0 102 8 13056 10 13056 10 str 1 24 2 12480 9 25536 19 dict of sugar.graphics.animator.Animator 2 54 4 12448 9 37984 28 dbus.String 3 64 5 8704 6 46688 34 dict (no owner) 4 16 1 8320 6 55008 40 dict of sugar.graphics.icon._IconBuffer 5 212 16 7632 6 62640 46 types.MethodType 6 4 0 6688 5 69328 51 dict of sugar.graphics.palette.Palette 7 4 0 6688 5 76016 56 dict of view.BuddyMenu.BuddyMenu 8 70 5 4576 3 80592 59 list 9 20 1 4272 3 84864 62 unicode

[frances]

Partition of a set of 1339 objects. Total size = 136740 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0    102   8    13056  10     13056  10 str
     1     24   2    12480   9     25536  19 dict of sugar.graphics.animator.Animator
     2     54   4    12448   9     37984  28 dbus.String
     3     64   5     8704   6     46688  34 dict (no owner)
     4     16   1     8320   6     55008  40 dict of sugar.graphics.icon._IconBuffer
     5    212  16     7632   6     62640  46 types.MethodType
     6      4   0     6688   5     69328  51 dict of sugar.graphics.palette.Palette
     7      4   0     6688   5     76016  56 dict of view.BuddyMenu.BuddyMenu
     8     70   5     4576   3     80592  59 list
     9     20   1     4272   3     84864  62 unicode

[mchua]

Closing this as per QA meeting today - probably fixed, but hard to verify absolutely that the problem's fixed. If more memory problems come up later, we will check them out for the next build.