On Tue, Dec 14, 2010 at 5:26 PM, Russell Owen <ro...@uw.edu> wrote:
> On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root <ben.r...@ou.edu> wrote:
>
>>
>>
>> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen <ro...@uw.edu> 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.edu> 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
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
