Hello,
For the 2.1.1 release (due Monday) I have added in a "Widget Counter"
popup, which you can use to keep track of how many widgets there are in
Analysis. I would say that if there are more memory leaks then there is a
good chance that it is down to widgets not being deleted when they should
be. (It is not the only type of Tk memory leak though, just the easiest
to notice via something like the counter. And there are still potential C
leaks.)
So in 2.1.1 under the Other menu at the bottom is a Widget Counter option.
You can get an automatic update every N seconds (you choose N, the default
is 60 seconds). If you keep it open and notice it keep going up then it
would be useful to know what dialog(s) you are using that might be
responsible. So when you first open a dialog you expect the count to go
up. And, for example, if you display a 3D peak list in the peak table
after having looked at a 2D peak list, then you might expect the count to
go up, but if you do this more than once then it should only go up if when
going back to the 2D it goes down. Basically, if it keeps going upwards
after you have settled into work then something is probably leaking.
(This replaces the object count logger from Analysis 1.0, which was a bit
too nebulous to be very useful.)
Wayne
On Fri, 9 Oct 2009, Wayne Boucher wrote:
> Hello,
>
> The good news is that I managed to find some pretty bad memory leaks in
> Analysis 2.1. Some of them might be issues in 2.0/1.0 but some are
> definitely new to 2.1. They were all Tk issues.
>
> One was a bug in Tkinter, which they supposedly fixed at the end of 2008 so
> ought to be in recent 2.5/2.6 releases (none of which we ourselves use).
> (Apparently the bug has been known to be around since 2005 and somehow never
> got fixed.) I added some code in our code to imitate their bug fix.
> (Fortunately we subclass most of the Tkinter widgets to add extra
> functionality so the fix was only needed in one file.)
>
> The other leaks are known Tk issues about how you have to explicitly
> delete/destroy old commands and event callbacks before you set new ones in
> place. There might well be other examples of this in the code, so more work
> will need to be done looking for them.
>
> We're hoping to do a release on Monday which will have all these fixes.
>
> Wayne
>
|