You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(3) |
2
(4) |
3
|
4
(2) |
|
5
|
6
(4) |
7
(11) |
8
(7) |
9
(9) |
10
(3) |
11
|
|
12
|
13
(4) |
14
(1) |
15
(24) |
16
(8) |
17
(11) |
18
(6) |
|
19
(2) |
20
(14) |
21
(13) |
22
(14) |
23
(3) |
24
(6) |
25
(2) |
|
26
|
27
(9) |
28
(18) |
29
(7) |
30
(15) |
31
(5) |
|
|
From: Eric F. <ef...@ha...> - 2008-10-01 23:45:18
|
Mátyás János wrote: > Hi, > > I'm looking for memory leaks in a python application and found leaks in > matplotlib. The application is graphic intensive. Each time it updates > the screen, matplotlib allocates another 5-10 megabytes memory for the > new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does not free up the buffers > allocated for the previous content. > This sounds to me like a pygtk bug, not a matplotlib bug; a gtk object is hanging around after its reference has been deleted. What versions of gtk and pygtk are you using? This sounds dimly familiar. I don't know enough about gtk and pygtk to help, but I am sure the people who do know more will want to know the version. Eric > I switched on garbage collection debugging with: > > import gc > gc.enable() > gc.set_debug(gc.DEBUG_LEAK) > > and tried to delete the leaking objects: > > --- ./lib/matplotlib/backends/backend_gtkagg.py 2008-06-23 > 04:09:29.000000000 +0200 ++ > + /usr/lib/python2.4/site-packages/matplotlib-0.91.4-py2.4-linux-i686.egg/matplotlib/backends/backend_gtkagg.py > 2008-10-02 00:05:32.000000000 +0200 @@ -3,6 +3,7 @@ """ > from __future__ import division > import os > +import gc > > import matplotlib > from matplotlib.figure import Figure > @@ -82,8 +83,17 @@ > h = int(ren.height) > pixbuf = gtk.gdk.pixbuf_new_from_data( > buf, gtk.gdk.COLORSPACE_RGB, True, 8, w, h, w*4) > - pixmap.draw_pixbuf(pixmap.new_gc(), pixbuf, 0, 0, 0, 0, w, h, > + g = pixmap.new_gc() > + pixmap.draw_pixbuf(g, pixbuf, 0, 0, 0, 0, w, h, > gtk.gdk.RGB_DITHER_NONE, 0, 0) > + > + print "XXXXXXXXXX", pixbuf, > g,pixbuf.__grefcount__,g.__grefcount__ > + print gc.get_referrers(pixbuf) > + print gc.get_referrers(g) > + del pixbuf > + del g > + gc.collect() > + > if DEBUG: print 'FigureCanvasGTKAgg.render_figure done' > > def blit(self, bbox=None): > > > The __grefcount__ values are 1 but the memory is not freed up even after > gc.collect(). > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Mátyás J. <mj...@gm...> - 2008-10-01 22:49:00
|
Hi,
I'm looking for memory leaks in a python application and found leaks in
matplotlib. The application is graphic intensive. Each time it updates
the screen, matplotlib allocates another 5-10 megabytes memory for the
new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does not free up the buffers
allocated for the previous content.
I switched on garbage collection debugging with:
import gc
gc.enable()
gc.set_debug(gc.DEBUG_LEAK)
and tried to delete the leaking objects:
--- ./lib/matplotlib/backends/backend_gtkagg.py 2008-06-23
04:09:29.000000000 +0200 ++
+ /usr/lib/python2.4/site-packages/matplotlib-0.91.4-py2.4-linux-i686.egg/matplotlib/backends/backend_gtkagg.py
2008-10-02 00:05:32.000000000 +0200 @@ -3,6 +3,7 @@ """
from __future__ import division
import os
+import gc
import matplotlib
from matplotlib.figure import Figure
@@ -82,8 +83,17 @@
h = int(ren.height)
pixbuf = gtk.gdk.pixbuf_new_from_data(
buf, gtk.gdk.COLORSPACE_RGB, True, 8, w, h, w*4)
- pixmap.draw_pixbuf(pixmap.new_gc(), pixbuf, 0, 0, 0, 0, w, h,
+ g = pixmap.new_gc()
+ pixmap.draw_pixbuf(g, pixbuf, 0, 0, 0, 0, w, h,
gtk.gdk.RGB_DITHER_NONE, 0, 0)
+
+ print "XXXXXXXXXX", pixbuf,
g,pixbuf.__grefcount__,g.__grefcount__
+ print gc.get_referrers(pixbuf)
+ print gc.get_referrers(g)
+ del pixbuf
+ del g
+ gc.collect()
+
if DEBUG: print 'FigureCanvasGTKAgg.render_figure done'
def blit(self, bbox=None):
The __grefcount__ values are 1 but the memory is not freed up even after
gc.collect().
|
|
From: Erik T. <eri...@gm...> - 2008-10-01 06:48:20
|
Sorry for the dealyed reply - I've been out of town... I posted to the patch tracker, and am dutifully pinging :) On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <jd...@gm...> wrote: > On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote: >> Attached is a diff against revision 6115 that contains a patch to >> improve the behavior of the legend function when showing legends for > > Erik, > > I haven't had a chance to get to this yet. Could you please also post > it on the sf patch tracker so it doesn't get dropped, and ping us with > a reminder in a few days if nothing has happened.... > > JDH > |