[sugar] end of internship

[Tomeu Vizoso]

On Thu, Oct 9, 2008 at 12:12 AM, Federico Mena Quintero
<federico at novell.com> wrote:
> On Tue, 2008-10-07 at 18:26 +0200, Tomeu Vizoso wrote:
>
>> - Developed a tool for monitoring memory allocation inside the python
>> interpreter. Code:
>> http://dev.laptop.org/git?p=users/rlucchese/python-allocstatsmodule/.git;a=summary
>
> Nice, nice, nice!  Is this something we could use for the bloaty python
> thingies we have around in GNOME? :)

I think so, but plays a relatively small role in the whole profiling
process. Most important is to remove leaks, that are unfortunately
very common in Pygtk apps.

About leak debugging of Pygtk apps, we have done as follows:

== Look for actions in the UI that result in unbounded allocations ==

Use Riccardo's allocstats module to periodically print allocation
stats, for example in an idle handler or a key event handler.

When you find an UI action that results in net allocation every time
the UI is returned to its previous state, note this UI action as
leaky.

== Remove all leaks from the python side using Guppy's heapy ==

Connect from another python shell session to the debugged process
using heapy's monitor:

http://guppy-pe.sourceforge.net/heapy_Use.html#heapykinds.Use.monitor

Reset the heap to zero, perform the UI action, then print the heap.
Find a class that makes sense from the application logic POV, then
check why it's being hold in memory. Most probably will be because an
instance belonging to the base state of the app is holding a reference
to it. And the most common cause is because the shorter-lived object
is listening on a signal from the longer-lived object. If the
shorter-lived object is a widget, disconnect those signals in its
destroy signal handler.

http://guppy-pe.sourceforge.net/
http://gentooexperimental.org/~ferringb/heapy.rst
http://blog.redinnovation.com/2008/03/07/debugging-django-memory-leak-with-trackrefs-and-guppy/
http://wiki.laptop.org/go/Memory_leak_testing

== remove all leaks from the C GObject side using refdbg ==

If after removing all leaks from the python side, memory allocations
continue to grow, then we have leaks in the C side, most probably on C
code local to the app, which is presumably less debugged that Pygtk
itself.

Get refdbg, and use it as you would do with a normal Gtk app, check
any instances that get referenced more than unreferenced and that
should get released when the UI action finishes but doesn't. Then add
an unref somewhere ;)

http://refdbg.sourceforge.net/

Sorry this is so vague and improvised, we should do a proper HOWTO out
of it, but time doesn't abound around here...

HTH,

Tomeu