704
edits
Changes
Jump to navigation
Jump to search
m
Development Team/Memory/Leak testing (view source)
Revision as of 00:47, 10 October 2009
, 00:47, 10 October 2009Created page with 'These are instructions on how to test for memory leaks in Sugar. == Install guppy == If you don't already have guppy on the XO you want to test, you'll have to download and ins…'
These are instructions on how to test for memory leaks in Sugar.
== Install guppy ==
If you don't already have guppy on the XO you want to test, you'll have to download and install it. In [[Terminal]], as [[root]]:
<pre>
wget http://dev.laptop.org/~tomeu/guppy-0.1.9-1.i386.rpm
rpm -i guppy-0.1.9-1.i386.rpm
</pre>
Edit ''/usr/bin/sugar-shell'' with
<code>
nano /usr/bin/sugar-shell
</code>
(or whatever your favorite text editor is) and add a line that reads
<code>
import guppy.heapy.RM
</code>
Then restart Sugar (ctrl-alt-erase).
== Starting a heapy session ==
[[ssh into the XO]] from another computer. We'll call this the Monitor Computer, and it should be separate from the XOs you are testing. When we observe Sugar, it is best not use it for anything else than to execute the test case. From your Monitor computer, in the shell you're ssh'd into your XO with:
<pre>
su - olpc
python -c "from guppy import hpy;hpy().monitor()"
sc 1
int
</pre>
== Running a test ==
From your monitor computer:
<code>
hp.setref()
</code>
Then, on your XO, do whatever action you're testing memory leaks for. (For instance, start and then close an Activity.)
Go back to your monitor computer and type:
<code>
hp.heap()
</code>
== Reading the results ==
You'll see a table that looks like this:
<code>
>>> hp.heap()
Partition of a set of 1019 objects. Total size = 89364 bytes.
Index Count % Size % Cumulative % Kind (class / dict of class)
0 25 2 13000 15 13000 15 dict of sugar.graphics.animator.Animator
1 12 1 6240 7 19240 22 dict of sugar.graphics.icon._IconBuffer
2 156 15 5616 6 24856 28 types.MethodType
3 3 0 5016 6 29872 33 dict of sugar.graphics.palette.Palette
4 82 8 4668 5 34540 39 str
5 106 10 4192 5 38732 43 tuple
6 8 1 4160 5 42892 48 dict of sugar.graphics.palette.MouseSpeedDetector
7 55 5 3776 4 46668 52 list
8 2 0 3344 4 50012 56 dict of view.BuddyMenu.BuddyMenu
9 2 0 3344 4 53356 60 dict of view.palettes.CurrentActivityPalette
<80 more rows. Type e.g. '_.more' to view.>
</code>
'''hp.heap()''' prints a summary of the contents of the python heap, which is where python places objects we ask it to create. The most interesting part is this line:
<code>
Partition of a set of 1019 objects. Total size = 89364 bytes.
</code>
This would mean that, since the last time we called hp.setref(), 219 new objects have been placed on the heap and they take up 18212 bytes in total. This doesn't necessarily mean we are leaking all these 219 objects, though - but if you repeat this procedure several times...
<code>
hp.setref()
*do the action you're testing in Sugar*
hp.heap()
</code>
and you see the amount of bytes growing steadily, we may have a bug. Look at anything that is over 10kb or so.
== Test variants ==
=== Repeated leak testing ===
A more definite test for leaks is the following:
<code>
hp.setref()
*do the action you're testing in Sugar 9 times*
hp.heap()
</code>
...and then look for new objects in quantities that are multiple of 9. Those will probably be leaks.
=== Without collaboration ===
If you run a test multiple times and get results with a lot of variance, it may be due to collaboration activity (especially if you're in a radio-noisy environment with many XOs). You can solve this by disabling radio (in the Sugar Control Panel) and using an usb-to-ethernet dongle to give the XO a wired connection to ssh into.
== Install guppy ==
If you don't already have guppy on the XO you want to test, you'll have to download and install it. In [[Terminal]], as [[root]]:
<pre>
wget http://dev.laptop.org/~tomeu/guppy-0.1.9-1.i386.rpm
rpm -i guppy-0.1.9-1.i386.rpm
</pre>
Edit ''/usr/bin/sugar-shell'' with
<code>
nano /usr/bin/sugar-shell
</code>
(or whatever your favorite text editor is) and add a line that reads
<code>
import guppy.heapy.RM
</code>
Then restart Sugar (ctrl-alt-erase).
== Starting a heapy session ==
[[ssh into the XO]] from another computer. We'll call this the Monitor Computer, and it should be separate from the XOs you are testing. When we observe Sugar, it is best not use it for anything else than to execute the test case. From your Monitor computer, in the shell you're ssh'd into your XO with:
<pre>
su - olpc
python -c "from guppy import hpy;hpy().monitor()"
sc 1
int
</pre>
== Running a test ==
From your monitor computer:
<code>
hp.setref()
</code>
Then, on your XO, do whatever action you're testing memory leaks for. (For instance, start and then close an Activity.)
Go back to your monitor computer and type:
<code>
hp.heap()
</code>
== Reading the results ==
You'll see a table that looks like this:
<code>
>>> hp.heap()
Partition of a set of 1019 objects. Total size = 89364 bytes.
Index Count % Size % Cumulative % Kind (class / dict of class)
0 25 2 13000 15 13000 15 dict of sugar.graphics.animator.Animator
1 12 1 6240 7 19240 22 dict of sugar.graphics.icon._IconBuffer
2 156 15 5616 6 24856 28 types.MethodType
3 3 0 5016 6 29872 33 dict of sugar.graphics.palette.Palette
4 82 8 4668 5 34540 39 str
5 106 10 4192 5 38732 43 tuple
6 8 1 4160 5 42892 48 dict of sugar.graphics.palette.MouseSpeedDetector
7 55 5 3776 4 46668 52 list
8 2 0 3344 4 50012 56 dict of view.BuddyMenu.BuddyMenu
9 2 0 3344 4 53356 60 dict of view.palettes.CurrentActivityPalette
<80 more rows. Type e.g. '_.more' to view.>
</code>
'''hp.heap()''' prints a summary of the contents of the python heap, which is where python places objects we ask it to create. The most interesting part is this line:
<code>
Partition of a set of 1019 objects. Total size = 89364 bytes.
</code>
This would mean that, since the last time we called hp.setref(), 219 new objects have been placed on the heap and they take up 18212 bytes in total. This doesn't necessarily mean we are leaking all these 219 objects, though - but if you repeat this procedure several times...
<code>
hp.setref()
*do the action you're testing in Sugar*
hp.heap()
</code>
and you see the amount of bytes growing steadily, we may have a bug. Look at anything that is over 10kb or so.
== Test variants ==
=== Repeated leak testing ===
A more definite test for leaks is the following:
<code>
hp.setref()
*do the action you're testing in Sugar 9 times*
hp.heap()
</code>
...and then look for new objects in quantities that are multiple of 9. Those will probably be leaks.
=== Without collaboration ===
If you run a test multiple times and get results with a lot of variance, it may be due to collaboration activity (especially if you're in a radio-noisy environment with many XOs). You can solve this by disabling radio (in the Sugar Control Panel) and using an usb-to-ethernet dongle to give the XO a wired connection to ssh into.