Memory leaks

Development matplotlib-devel
21

Interesting. I don't get that, but I do get some random segfaults (I got lucky the first time I tested).

I'm awfully surprised that wx.GetApp() would return an iterator, as you are getting, so maybe it's corruption of some sort?

Reverting to revision 3441 on backend_wx.py does resolve this issue for me, so it is related to removing the wxapp global variable. While I like the idea of removing global variables, that was problematic, since when the wxapp variable is dereferenced, the whole wx.App is destructed, (hence, I believe the segfaults). Since I didn't want to just put the wxapp global variable back in, I assigned it to the figure that creates it, therefore stick around as long as the figure does. (Is that the correct thing for its lifetime?) Anyway, it seems to fix memleak_gui.py for me. Ken and Tim will probably want to check that I didn't cause more mainloops to start than necessary in the process.

Also, I'm a little puzzled by this code in show() in backend_wx.py:

        wxapp = wx.GetApp()
        if wxapp is not None:
            # wxPython 2.4 has no wx.App.IsMainLoopRunning() method
            imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False)
            if imlr():
                wxapp.MainLoop()

If I'm reading this correctly, shouldn't it be "if not imlr()"? If it is correct, maybe it needs a comment as to why mainloops should be started if a mainloop is already running.

Cheers,
Mike

Eric Firing wrote:

···

Mike,

New exception:

efiring@...340...:~/programs/py/mpl/tests$ python ../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > ~/temp/memleak_wx_0705.asc
Traceback (most recent call last):
  File "../matplotlib_units/unit/memleak_gui.py", line 58, in <module>
    pylab.close(fig)
  File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", line 742, in close
    _pylab_helpers.Gcf.destroy(manager.num)
  File "/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", line 28, in destroy
    figManager.destroy()
  File "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1405, in destroy
    self.frame.Destroy()
  File "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1364, in Destroy
    wxapp.Yield()
AttributeError: 'listiterator' object has no attribute 'Yield'

Eric

22

Michael Droettboom wrote:

Interesting. I don't get that, but I do get some random segfaults (I got lucky the first time I tested).

I'm awfully surprised that wx.GetApp() would return an iterator, as you are getting, so maybe it's corruption of some sort?

Reverting to revision 3441 on backend_wx.py does resolve this issue for me, so it is related to removing the wxapp global variable. While I

[...]

Works for me now, and the result is attached. Object count is still climbing.

Eric

memleak_wx_0705.asc (4.86 KB)

23

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

If that doesn't make it immediately obvious, I'll try this on my Ubuntu box at home and see if I can reproduce what you're seeing.

Cheers,
Mike

Eric Firing wrote:

memleak_gui_wx.py (1.01 KB)

···

Michael Droettboom wrote:

Interesting. I don't get that, but I do get some random segfaults (I got lucky the first time I tested).

I'm awfully surprised that wx.GetApp() would return an iterator, as you are getting, so maybe it's corruption of some sort?

Reverting to revision 3441 on backend_wx.py does resolve this issue for me, so it is related to removing the wxapp global variable. While I

[...]

Works for me now, and the result is attached. Object count is still climbing.

Eric
------------------------------------------------------------------------

# columns are: iteration, OS memory (k), number of python objects
#
   0 18849 75791
  10 18849 75831
  20 18849 75871
  30 18849 75911
  40 18930 75951
  50 18930 75991
  60 19038 76031
  70 19038 76071
  80 19038 76111
  90 19038 76151
100 19124 76191
110 19124 76231
120 19235 76271
130 19235 76311
140 19316 76351
150 19316 76391
160 19417 76431
170 19417 76471
180 19417 76511
190 19513 76551
200 19513 76591
210 19513 76631
220 19612 76671
230 19612 76711
240 19612 76751
250 19710 76791
260 19710 76831
270 19710 76871
280 19800 76911
290 19800 76951
300 19800 76991
310 19893 77031
320 19893 77071
330 19893 77111
340 19978 77151
350 19978 77191
360 20088 77231
370 20088 77271
380 20088 77311
390 20192 77351
400 20192 77391
410 20192 77431
420 20192 77471
430 20274 77511
440 20274 77551
450 20374 77591
460 20374 77631
470 20374 77671
480 20484 77711
490 20484 77751
500 20484 77791
510 20588 77831
520 20588 77871
530 20588 77911
540 20588 77951
550 20683 77991
560 20683 78031
570 20683 78071
580 20763 78111
590 20796 78151
600 20861 78191
610 20961 78231
620 20961 78271
630 20961 78311
640 21060 78351
650 21060 78391
660 21060 78431
670 21156 78471
680 21156 78511
690 21156 78551
700 21254 78591
710 21254 78631
720 21254 78671
730 21353 78711
740 21353 78751
750 21353 78791
760 21442 78831
770 21442 78871
780 21442 78911
790 21528 78951
800 21528 78991
810 21638 79031
820 21638 79071
830 21638 79111
840 21638 79151
850 21733 79191
860 21733 79231
870 21733 79271
880 21820 79311
890 21820 79351
900 21931 79391
910 21931 79431
920 21931 79471
930 21931 79511
940 22015 79551
950 22015 79591
960 22126 79631
970 22126 79671
980 22126 79711
990 22126 79751
1000 22207 79791
1010 22207 79831
1020 22298 79871
1030 22298 79911
1040 22335 79951
1050 22401 79991
1060 22503 80031
1070 22503 80071
1080 22503 80111
1090 22601 80151
1100 22601 80191
1110 22601 80231
1120 22699 80271
1130 22699 80311
1140 22699 80351
1150 22798 80391
1160 22798 80431
1170 22798 80471
1180 22897 80511
1190 22897 80551
1200 22897 80591
1210 22995 80631
1220 22995 80671
1230 22995 80711
1240 23086 80751
1250 23086 80791
1260 23086 80831
1270 23180 80871
1280 23180 80911
1290 23283 80951
1300 23283 80991
1310 23283 81031
1320 23283 81071
1330 23366 81111
1340 23366 81151
1350 23475 81191
1360 23475 81231
1370 23475 81271
1380 23475 81311
1390 23552 81351
1400 23552 81391
1410 23643 81431
1420 23643 81471
1430 23595 81511
1440 23700 81551
1450 23808 81591
1460 23808 81631
1470 23808 81671
1480 23787 81711
1490 23852 81751
1500 23951 81791
1510 24048 81831
1520 24048 81871
1530 24048 81911
1540 24146 81951
1550 24146 81991
1560 24146 82031
1570 24247 82071
1580 24247 82111
1590 24247 82151
1600 24344 82191
1610 24344 82231
1620 24344 82271
1630 24442 82311
1640 24442 82351
1650 24442 82391
1660 24542 82431
1670 24542 82471
1680 24542 82511
1690 24639 82551
1700 24639 82591
1710 24639 82631
1720 24738 82671
1730 24738 82711
1740 24738 82751
1750 24837 82791
1760 24837 82831
1770 24837 82871
1780 24935 82911
1790 24935 82951
1800 24935 82991
1810 25025 83031
1820 25025 83071
1830 25025 83111
1840 25118 83151
1850 25118 83191
1860 25104 83231
1870 25170 83271
1880 25281 83311
1890 25281 83351
1900 25281 83391
1910 25385 83431
1920 25385 83471
1930 25385 83511
1940 25362 83551
1950 25400 83591
1960 25469 83631
1970 25596 83671
1980 25596 83711
1990 25693 83751
2000 25693 83791
# columns above are: iteration, OS memory (k), number of python objects
#
# uncollectable list:
#
# Backend WX, toolbar toolbar2
# wxPython version: 2.8.1.1
# Averaging over loops 1000 to 2000
# Memory went from 22207k to 25693k
# Average memory consumed per loop: 3.4860k bytes

24

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

25

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

And here is the result of the script modified for gtk:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1
55352 55417
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2
55352 55421
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>

uncollectable list:

Eric

26

Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).

It looks like wxPython doesn't retain a reference to the wxApp PyObj for you:

  kmcivor@...536...:~/Projects/matplotlib-svn$ pythonw
  Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
  [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import wx
  >>> app = wx.PySimpleApp()
  >>> del app
  >>> wx.GetApp()
  Segmentation fault

I'm awfully surprised that wx.GetApp() would return an iterator, as you
are getting, so maybe it's corruption of some sort?

My guess is that Eric got lucky and ob_type was pointing to the listiterator's C type instance.

Since I didn't want to just put the wxapp global variable back in, I assigned it to the figure that creates it, therefore stick around as long as the figure does. (Is that the correct thing for its lifetime?)

I don't think this will work if you create two figures, destroy the first one, and then create another figure. Once created, the wxApp needs to exist for the life of the python process. I'll go ahead an put the global variable back in.

Also, I'm a little puzzled by this code in show() in backend_wx.py:

        wxapp = wx.GetApp()
        if wxapp is not None:
            # wxPython 2.4 has no wx.App.IsMainLoopRunning() method
            imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False)
            if imlr():
                wxapp.MainLoop()

If I'm reading this correctly, shouldn't it be "if not imlr()"?

Yes, it should be. I'll try to code with my eyes open from now on. :-/

Ken

···

On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:

27

Yep. Nothing obvious. I'll have to have a look on Ubuntu and see if that makes a difference.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

28

That is at least something to go by. :wink:

Thanks,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

And here is the result of the script modified for gtk:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1
55352 55417
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2
55352 55421
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>

uncollectable list:

Eric

29

Ken McIvor wrote:

···

On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:

Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).

It looks like wxPython doesn't retain a reference to the wxApp PyObj for you:

    kmcivor@...536...:~/Projects/matplotlib-svn$ pythonw
    Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
    [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import wx
    >>> app = wx.PySimpleApp()
    >>> del app
    >>> wx.GetApp()
    Segmentation fault

This qualifies as a wx bug, doesn't it? If wx doesn't retain the reference, then instead of a segfault shouldn't it raise an exception?

Eric

30

This qualifies as a wx bug, doesn't it?

I believe so. I'll file it.

If wx doesn't retain the reference, then instead of a segfault shouldn't it raise an exception?

I'd expect wx.GetApp() to work like the rest of wxPython and always return the wx.App instance.

This has been fixed in revision 3463.

Ken

···

On Jul 5, 2007, at 3:48 PM, Eric Firing wrote:

31

Ken McIvor wrote:

This qualifies as a wx bug, doesn't it?

I believe so. I'll file it.

I agree - a segfault is ALWAYS a bug.

If wx doesn't retain the reference, then instead of a segfault shouldn't it raise an exception?

I'd expect wx.GetApp() to work like the rest of wxPython and always return the wx.App instance.

If a wx.App has not been created, it returns None:

>>> import wx
>>> wx.GetApp()
>>> a = wx.GetApp()
>>> print a
None

Which is probably what it should do if the wxApp() has been deleted.

In any case, you can only create one wxApp per program instance, and it can not be destroyed and re-started, so keeping a global instance around is probably the way to go.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

32

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose class subclasses a Wx class. There is a fix for this that made it into wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to wxPython-2.8.4 should upgrade. There are binary packages available for a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know if this qualifies for the kind of fix they would normally make as a maintenance release. Promisingly, my bug was confirmed within about five minutes of filing it.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

33

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose class subclasses a Wx class. There is a fix for this that made it into wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to wxPython-2.8.4 should upgrade. There are binary packages available for a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know if this qualifies for the kind of fix they would normally make as a maintenance release. Promisingly, my bug was confirmed within about five minutes of filing it.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

34

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose class subclasses a Wx class. There is a fix for this that made it into wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to wxPython-2.8.4 should upgrade. There are binary packages available for a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know if this qualifies for the kind of fix they would normally make as a maintenance release. Promisingly, my bug was confirmed within about five minutes of filing it.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

35

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 should upgrade. There are binary packages available for
a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

36

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 should upgrade. There are binary packages available for
a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

37

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 upgrade. There are binary packages available for
a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release, but I thought it was worth trying.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

38

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 upgrade. There are binary packages available for
a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release, but I thought it was worth trying.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

39

I had no trouble reproducing this on my Ubuntu Feisty box.

It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1

I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.

** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 upgrade. There are binary packages available for
a number of distributions on wxpython.org. **

As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release, but I thought it was worth trying.

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Interesting...

When you get a chance, would you mind running the attached script? This is how I was finding object leaks before. It takes a single commandline argument that is the number of iterations. Can you send me the outputs from 1 and 2 iterations? That way we should be able to see what type of object is being leaked, which is a good first step.

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

efiring@...340...:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>

uncollectable list:

Eric

40

My sincere apologies for the multiple copies of the e-mail sent this morning. I was getting "SMTP server down" messages, but clearly the messages were sent anyway.

I'm not a spammer, really! :wink:

Mike