On Tue, Dec 14, 2010 at 5:26 PM, Russell Owen <ro...@uw...> wrote: > On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote: > > On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root <ben...@ou...> wrote: > >> >> >> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen <ro...@uw...> wrote: >> >>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote: >>> >>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> wrote: >>> >>>> I tried the test script on linux using matplotlib svn trunk rev8840 >>>> (which appears to include your patch) and found a leak that starts out >>>> small but gets systematically larger. This is with Python 2.6.5 and >>>> Tkinter built against Tcl/Tk 8.4.13. >>>> >>>> Is anyone else seeing this? >>>> >>>> time rss memory mem/sec >>>> (sec) (kb) (kb/sec) >>>> 0.0 36816 nan >>>> 5.0 36860 nan >>>> 10.0 36860 0.0 >>>> 15.1 36860 0.0 >>>> 20.1 36860 0.0 >>>> 25.1 36896 1.8 >>>> ... >>>> 326.5 36896 0.1 >>>> 331.6 36972 0.3 >>>> ... >>>> 401.9 36972 0.3 >>>> 406.9 36980 0.3 >>>> ... >>>> >>>> 602.8 37684 1.4 >>>> 607.8 37700 1.4 >>>> >>>> This is different behavior than on Mac OS X, but still alarming. >>>> >>>> -- Russell >>>> >>>> >>> Russell, >>> >>> I am curious, I recently ran into problems with mixing builds of numpy >>> and matplotlib at various levels of revisions. I eventually had to do a >>> complete clean rebuild. Note, what I mean by a complete clean rebuild is >>> that I removed the numpy and matplotlib source directories and re-checkout >>> the codes from source and then rebuild. I would be curious if the problem >>> persists after that. >>> >>> >>> An interesting question. I can say that this was a clean build of >>> matplotlib since I ran it "in place" (in build/lib.linux-x86_64-2.6/) after >>> building it rather than installing it in site-packages to avoid messing up >>> other users (on the linux system this was a shared python). I modified the >>> script to print matplotlib.__file__ to make sure I was running the right >>> version. I doubt it was a clean build of numpy. But considering no numerics >>> are occurring in this example (it is literally just creating an Axes on a >>> Canvas and calling canvas.draw() repeatedly) do you think numpy could >>> possibly come into this? >>> >>> >> It is quite possible. Numpy is used extensively throughout the matplotlib >> system, regardless of whether you are using it or not. Also, the fact that >> you are on a shared system is interesting. For those situations, try doing >> >> "python setupegg.py develop --user" >> >> for the build command. What this does is builds everything in-place (the >> build directory symbolically links to those files), and then uses your >> ~/.local directory to install an egg.lnk file to point back to the build >> directory. This should have higher search precedence than the system >> install of matplotlib and numpy. >> >> Note, I had mixed success with this approach on a RHEL (5?) system >> recently. I don't know how recently ~/.local became widely accepted among >> various distros. >> >> >>> Might you run the script on your system with the clean build? >>> >>> -- Russell >>> >>> >> I will give it a shot (once my other analysis programs are done for the >> day). >> >> Ben Root >> > > I ran your script from the url you posted earlier. My build does not show > any leak for about a minute. I am fairly certain that what we have here is > a build mixing issue or an issue with an unknown combination of libraries > interacting. Could you post your build logs? > > Ben Root > > > I tried your suggestion -- installing numpy from scratch (deleting the old > numpy first) and then building matplotlib fresh. Here are my build logs: > <http://www.astro.washington.edu/users/rowen/python/numpy_build_log.txt> > < > http://www.astro.washington.edu/users/rowen/python/matplotlib_build_log.txt > > > > Much like last time (with a fresh matplotlib) the test program shows no > leak at first, then it starts growing to alarming levels (though it took > longer to start leaking this time than it did last time): > > Interesting behavior to report. I did a completely clean rebuild on my other computer (Ubuntu 10.10) and the first matplotlib-related program that was used was this memory check program. It exhibited a memory leak for the very first run. However, after ending that program and starting it back up, the memory levels were lower and very steady. I also noticed for the runs where the memory levels were steady, I could make the memory levels go slightly up if I interacted with the figure window (moving it and such). I did do a long run (600+ seconds) and I did get a memory leak at around 600 second mark. I did *not* have the same problem, though, where the next run exhibits an immediate memory leak. Instead, the memory levels were consistent with previous runs. I will take a peek at your build logs tomorrow. There is something fishy happening, but I am not convinced that it is entirely an issue with matplotlib (although that first run behavior is bad...). Ben Root