From: Eric F. <ef...@ha...> - 2007-03-31 08:17:22
|
Tom Holroyd (NIH/NIMH) [E] wrote: > More info on the memory leaks. It has to do with GtkToolbar.insert(). > For example, in the function _init_toolbar2_4() in backend_gtk.py, > commenting out any of the self.insert() calls will change how much it > leaks. Comment them all out, plus the self.fileselect assignment (which > is very slow, by the way, and accounts for more leaks than other places) > and it'll leak minimally. > > Does that mean this is a bug in gtk? > I don't know. I have been experimenting with a simple pure pygtk demo (no mpl components). I was about to conclude that it leaked whenever the toplevel show() method was used, but I just now did another test that suggests this is not the case if the mainloop in started and the window is killed each time--which would be the normal mode of operation, but is tedious to test for large numbers of iterations. (It should be possible to simulate it instead.) I have not tried enough of such loops to be sure yet, but overall, I am suspecting that the problem in mpl is not inevitable but has to do with the way the gtk things are called and referenced. I think we have a similar problem with all interactive backends (the only one I didn't test is Qt4Agg) which also makes me suspect we are violating some gui rule, rather than that gtk, qt3, wx, and tk all have leaks. I added a MemoryMonitor class to cbook.py to make this testing a little easier. No docstrings yet, but it will be obvious what it does. Eric |