plt.close() not releasing memory? Or memory leak elsewhere?

Hi All

After spending all day working on this I have discovered that if I explicity change the matplotlib backend in spyder from ‘Qt4Agg’ to ‘Agg’ then my code executes as expected with no memory errors.

Any ideas about this? It seems like a bug in Qt4Agg of some kind—is there somewhere I should file a bug report?

Thanks

Sam

Which version of mpl are you using? There have already been some efforts to close out memory leaks and yours may already be fixed in the development version of mpl.

Ben Root

···

On Tue, May 22, 2012 at 8:44 AM, Stevenson, Samuel <Samuel.Stevenson@…4079…> wrote:

Hi All

After spending all day working on this I have discovered that if I explicity change the matplotlib backend in spyder from ‘Qt4Agg’ to ‘Agg’ then my code executes as expected with no memory errors.

Any ideas about this? It seems like a bug in Qt4Agg of some kind—is there somewhere I should file a bug report?

Thanks

Sam

Hi Ben

I am using 1.0.0. My colleague has 1.1.0 installed on his machine and is able to reproduce the same problem.

Thanks

Sam

···

From: ben.v.root@…287… [mailto:ben.v.root@…287…] On Behalf Of Benjamin Root
Sent: 22 May 2012 14:14
To: Stevenson, Samuel
Cc: matplotlib-users@lists.sourceforge.net
Subject: Re: [Matplotlib-users] plt.close() not releasing memory? Or memory leak elsewhere?

On Tue, May 22, 2012 at 8:44 AM, Stevenson, Samuel <Samuel.Stevenson@…4079…> wrote:

Hi All

After spending all day working on this I have discovered that if I explicity change the matplotlib backend in spyder from ‘Qt4Agg’ to ‘Agg’ then my code executes as expected with no memory errors.

Any ideas about this? It seems like a bug in Qt4Agg of some kind—is there somewhere I should file a bug report?

Thanks

Sam

Which version of mpl are you using? There have already been some efforts to close out memory leaks and yours may already be fixed in the development version of mpl.

Ben Root

Going through my old unresolved emails, I came across this one. I suspect that whatever has caused this problem in v1.1.0 is still present in v1.2.0 that we will be putting out an RC for. If you can make a small script that can demonstrate the memory leak, maybe we can track it down and nail this sucker before the final release?

Cheers!
Ben Root

···

On Tue, May 22, 2012 at 9:18 AM, Stevenson, Samuel <Samuel.Stevenson@…4079…> wrote:

Hi Ben

I am using 1.0.0. My colleague has 1.1.0 installed on his machine and is able to reproduce the same problem.

Thanks

Sam