wx.Window.GetSizeTuple keeps allocating integers

wxPython Users
1

Hi,

I am developing a signal visualization application with Enthought
Chaco (http://code.enthought.com/projects/chaco/). Chaco has a wx
backend. The application re-draws signal plots many times a second and
I have noticed that every screen update leaks a small amount of
memory. The leak originates from Chaco's fundamental paint operations
and I managed to reproduce it with a Chaco's example script (https://
svn.enthought.com/enthought/log/Chaco/trunk/examples/updating_plot/
updating_plot1.py).

Investigating the leak with valgrind massif (Valgrind: Table of Contents
manual/ms-manual.html) and gdb, I found out that every time the screen
is re-drawn, window size is requested with wx.Window.GetSizeTuple
(_wrap_Window_GetSizeTuple), which allocates a new integer object with
PyInt_FromLong (alias SWIG_From_int). It seems that those integers are
not deallocated as around every 40th call to PyInt_FromLong from
_wrap_Window_GetSizeTuple result in a fill_free_list allocation (in
Python's intobject.c) and virtually all calls to fill_free_list come
from _wrap_Window_GetSizeTuple.

Here is some output from massif, which shows that memory allocated as
integers by _wrap_Window_GetSizeTuple starts to dominate as the
application runs for a long time.

->02.25% (896,116B) 0x807D621: fill_free_list (intobject.c:51)

->02.25% (894,140B) 0x807D6DD: PyInt_FromLong (intobject.c:102)
> ->01.89% (752,856B) 0x46CE738: _wrap_Window_GetSizeTuple

(_core_wrap.cpp:2932)

···

--
->04.70% (2,098,512B) 0x807D621: fill_free_list (intobject.c:51)

->04.70% (2,096,536B) 0x807D6DD: PyInt_FromLong (intobject.c:102)
> ->04.18% (1,868,308B) 0x46CE738: _wrap_Window_GetSizeTuple

(_core_wrap.cpp:2932)
--
->07.86% (3,322,644B) 0x807D621: fill_free_list (intobject.c:51)

->07.86% (3,320,668B) 0x807D6DD: PyInt_FromLong (intobject.c:102)
> ->07.12% (3,009,448B) 0x46CE738: _wrap_Window_GetSizeTuple

(_core_wrap.cpp:2932)

I posted the bug report to Chaco mailing list (https://
mail.enthought.com/pipermail/enthought-dev/2009-July/023003.html), but
did not get a response with a solution. Also a Chaco bug report of the
leak has been created (https://svn.enthought.com/enthought/ticket/
1826).

Best Regards,
Joonas Paalasmaa
Finsor Ltd

2

Joonas Paalasmaa wrote:

Hi,

I am developing a signal visualization application with Enthought
Chaco (http://code.enthought.com/projects/chaco/). Chaco has a wx
backend. The application re-draws signal plots many times a second and
I have noticed that every screen update leaks a small amount of
memory. The leak originates from Chaco's fundamental paint operations
and I managed to reproduce it with a Chaco's example script (https://
svn.enthought.com/enthought/log/Chaco/trunk/examples/updating_plot/
updating_plot1.py).

Investigating the leak with valgrind massif (Valgrind: Table of Contents
manual/ms-manual.html) and gdb, I found out that every time the screen
is re-drawn, window size is requested with wx.Window.GetSizeTuple
(_wrap_Window_GetSizeTuple), which allocates a new integer object with
PyInt_FromLong (alias SWIG_From_int). It seems that those integers are
not deallocated as around every 40th call to PyInt_FromLong from
_wrap_Window_GetSizeTuple result in a fill_free_list allocation (in
Python's intobject.c) and virtually all calls to fill_free_list come
from _wrap_Window_GetSizeTuple.

Thanks for reporting this. You may want to try replacing GetSizeTuple with GetSize. It will return a wx.Size instead of a tuple, but it can behave like a tuple in most use cases, and it will avoid the code where the ref-count issue is probably at.

···

--
Robin Dunn
Software Craftsman