From: Thomas L. <ta...@ec...> - 2002-05-29 17:50:42
|
I'm still trying to track down the memory leak when setting the pinboard backdrop... Can anyone see what's wrong with this code? It creates a new pixbuf image and then, once a second, renders it as a pixmap and sets it as the window's background image. On my system (Debian/Unstable, XFree86 4.1) it will sit there not doing much, but if you drag a window over it (to cause redrawing) then the X server's memory starts to increase (about 1 Mb per second while dragging). Stop dragging, and the memory stops increasing until you start again. Quitting the program and starting it again, it continues eating memory where it left off (ie, you don't get the memory back!). Now: - Have I missed something obvious? - Does this happen for everyone, or is it just me? - Why only when redrawing the window AND changing the backdrop (remove either and it works fine). - Unreffing the pixmap after setting the style causes a segfault, so I take that as a hint that we shouldn't do that. #include <gtk/gtk.h> GdkPixbuf *pixbuf = NULL; static gboolean set_background(GtkWidget *win) { GtkStyle *style; GdkPixmap *pixmap; gdk_pixbuf_render_pixmap_and_mask(pixbuf, &pixmap, NULL, 0); style = gtk_style_new(); style->bg_pixmap[GTK_STATE_NORMAL] = pixmap; gtk_widget_set_style(win, style); g_object_unref(style); return TRUE; } int main(int argc, char **argv) { GtkWidget *win; gtk_init(&argc, &argv); pixbuf = gdk_pixbuf_new(GDK_COLORSPACE_RGB, FALSE, 8, 800, 800); win = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_widget_set_size_request(win, gdk_pixbuf_get_width(pixbuf), gdk_pixbuf_get_height(pixbuf)); gtk_widget_show(win); g_timeout_add(1000, (GSourceFunc) set_background, win); gtk_main(); return 0; } Puzzled, but possibly just need more sleep... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: <ju...@hu...> - 2016-03-19 14:12:57
|
Hi I found a memory leak. Just, the bookmarks menu is never destroyed. |
From: Ryan H. <rph...@en...> - 2002-05-30 07:33:10
|
On Wed, 2002-05-29 at 13:49, Thomas Leonard wrote: > I'm still trying to track down the memory leak when setting the pinboard > backdrop... > > Can anyone see what's wrong with this code? It creates a new pixbuf image > and then, once a second, renders it as a pixmap and sets it as the > window's background image. > > On my system (Debian/Unstable, XFree86 4.1) it will sit there not doing > much, but if you drag a window over it (to cause redrawing) then the X > server's memory starts to increase (about 1 Mb per second while dragging). > Stop dragging, and the memory stops increasing until you start again. > > Quitting the program and starting it again, it continues eating memory > where it left off (ie, you don't get the memory back!). > > Now: > > - Have I missed something obvious? > - Does this happen for everyone, or is it just me? > - Why only when redrawing the window AND changing the backdrop (remove > either and it works fine). > - Unreffing the pixmap after setting the style causes a segfault, so I > take that as a hint that we shouldn't do that. I'm not sure as to the reason, but I am definitely seeing a similar, and surely related, problem. After time running Rox with the pinboard background set, X memory usage goes through the roof, redrawing (shading, etc) becomes very slow. "but if you drag a window over it" I'm assuming you meant dragging windows over the pinboard to cause a redraw? This doesn't seem to cause it for me; at least not fast enough for me to notice. For me it seems to happen directly any time I change the background image. And, the symtoms seem to get worse over time. I'm not sure if this is due to killing and restarting Rox, as I've been doing that a lot lately. I'm also running Debian unstable. -- Ryan Patrick Harris (maxter) rph...@en... University of Michigan EECS http://maxtersbox.net |
From: Thomas L. <ta...@ec...> - 2002-05-31 11:57:56
|
On Thu, May 30, 2002 at 01:22:59AM -0400, Ryan Harris wrote: [ changing backdrop leaks memory ] > I'm not sure as to the reason, but I am definitely seeing a similar, and > surely related, problem. After time running Rox with the pinboard > background set, X memory usage goes through the roof, redrawing > (shading, etc) becomes very slow. > > "but if you drag a window over it" > > I'm assuming you meant dragging windows over the pinboard to cause a > redraw? This doesn't seem to cause it for me; at least not fast enough > for me to notice. For me it seems to happen directly any time I change > the background image. And, the symtoms seem to get worse over time. I'm > not sure if this is due to killing and restarting Rox, as I've been > doing that a lot lately. It used to happen all the time with the new pinboard code, but after I removed the ParentRelative stuff, it got more managable. > I'm also running Debian unstable. The xfree86 packager suggested I try with Section "Device" ... Option "NoAccel" in XF86Config-4 and that solves the problem for me. Well, except for making X unusably slow, but... Looks like it's fixed in 4.2. -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Stephen W. <wa...@ul...> - 2002-05-30 08:08:36
|
In message <200...@ev...> Thomas Leonard <ta...@ec...> scribbled: > Can anyone see what's wrong with this code? It creates a new pixbuf image > and then, once a second, renders it as a pixmap and sets it as the > window's background image. > > On my system (Debian/Unstable, XFree86 4.1) it will sit there not doing > much, but if you drag a window over it (to cause redrawing) then the X > server's memory starts to increase (about 1 Mb per second while dragging). > Stop dragging, and the memory stops increasing until you start again. Tried it on Solaris 8 but I didn't see the effect. Dragging a window over to force the redraw did not affect the X server's memory (steady at 0/192/310 MB according to System). -- Stephen Watson Physicist Ultra Electronics Ltd - Signature Management Systems (UESMS) Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 Email: wa...@ul... |
From: Filip V. R. <mec...@de...> - 2002-05-30 10:13:00
|
Hi, I don't have gtk2 handy here so I can't try it right now, but... On Wed, May 29, 2002 at 06:49:13PM +0100, Thomas Leonard wrote: > > - Unreffing the pixmap after setting the style causes a segfault, so I > take that as a hint that we shouldn't do that. Yet you create a new pixmap each time and don't unref the old one (you obviously can't anymore after you've left the callback) Have you also tried unreffing the pixmap after unreffing the style, or did you unref it before that? How about making style and pixmap globals, creating them only once at startup, and just only setting style in the callback instead of recreating the pixmap and style each time? Regards, Filip -- Why is "abbreviation" such a long word? -- Arthur Korn |
From: Thomas L. <ta...@ec...> - 2002-05-30 11:00:26
|
On Thu, May 30, 2002 at 12:17:42PM +0200, Filip Van Raemdonck wrote: > Hi, > > I don't have gtk2 handy here so I can't try it right now, but... > > On Wed, May 29, 2002 at 06:49:13PM +0100, Thomas Leonard wrote: > > > > - Unreffing the pixmap after setting the style causes a segfault, so I > > take that as a hint that we shouldn't do that. > > Yet you create a new pixmap each time and don't unref the old one (you > obviously can't anymore after you've left the callback) > Have you also tried unreffing the pixmap after unreffing the style, or did > you unref it before that? Doesn't work either way. The ref counting goes as follows (from printfs): 1. Create new pixmap (pixmap ref = 1) 2. set_style() (pixmap ref now 2) 3. unref style (pixmap ref still 2) [ wait] 4. Create new pixmap (old pixmap still has ref = 2) 5. set_style() (new = 2, old is now invalid) That is: - Setting the style increases the ref count by one. - Unsetting it decreases by two. My code therefore allows for this. Also, a refcounting error doesn't explain why: - Neither the program nor the X server grows when no window is being dragged over it. - XNest and other X servers don't seem to be affected. > How about making style and pixmap globals, creating them only once at > startup, and just only setting style in the callback instead of recreating > the pixmap and style each time? If the pixmap is only created once then there is no problem (which isn't much use for a backdrop setter ;-). -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Andras M. <ma...@ma...> - 2002-05-30 11:17:55
|
On Wed, May 29, 2002 at 18:49:13 +0100, Thomas Leonard wrote: > - Why only when redrawing the window AND changing the backdrop (remove > either and it works fine). Have you tried gtk_widget_set_double_buffered(win, FALSE)? (Just a lame suggestion...) -- Andras Mohari ma...@ma... |
From: Thomas L. <ta...@ec...> - 2002-05-30 11:37:06
|
On Thu, May 30, 2002 at 01:17:21PM +0200, Andras Mohari wrote: > On Wed, May 29, 2002 at 18:49:13 +0100, Thomas Leonard wrote: > > - Why only when redrawing the window AND changing the backdrop (remove > > either and it works fine). > > Have you tried gtk_widget_set_double_buffered(win, FALSE)? > (Just a lame suggestion...) That does seem to stop the leak. Now, for your bonus marks, explain why ;-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Andras M. <ma...@ma...> - 2002-05-30 12:22:56
|
On Thu, May 30, 2002 at 12:35:37 +0100, Thomas Leonard wrote: > On Thu, May 30, 2002 at 01:17:21PM +0200, Andras Mohari wrote: > > On Wed, May 29, 2002 at 18:49:13 +0100, Thomas Leonard wrote: > > > - Why only when redrawing the window AND changing the backdrop (remove > > > either and it works fine). > > > > Have you tried gtk_widget_set_double_buffered(win, FALSE)? > > (Just a lame suggestion...) > > That does seem to stop the leak. Now, for your bonus marks, explain why > ;-) Gee! :-) I can't explain why, it is beyond me. (I thought that maybe the bg pixmap is changed between calls to gdk_window_begin_paint_region() and gdk_window_end_paint() and that it somehow causes troubles. But I can't prove either...and I stop here before writing even more rubbish.) If somebody knows why, tell me too. -- Andras Mohari ma...@ma... |
From: Thomas L. <ta...@ec...> - 2002-05-30 14:10:04
|
On Thu, May 30, 2002 at 02:22:29PM +0200, Andras Mohari wrote: > On Thu, May 30, 2002 at 12:35:37 +0100, Thomas Leonard wrote: > > On Thu, May 30, 2002 at 01:17:21PM +0200, Andras Mohari wrote: > > > On Wed, May 29, 2002 at 18:49:13 +0100, Thomas Leonard wrote: > > > > - Why only when redrawing the window AND changing the backdrop > > > > (remove either and it works fine). > > > > > > Have you tried gtk_widget_set_double_buffered(win, FALSE)? > > > (Just a lame suggestion...) > > > > That does seem to stop the leak. Now, for your bonus marks, explain why > > ;-) > > Gee! :-) > > I can't explain why, it is beyond me. > (I thought that maybe the bg pixmap is changed between calls to > gdk_window_begin_paint_region() and gdk_window_end_paint() and that > it somehow causes troubles. But I can't prove either...and I stop > here before writing even more rubbish.) > > If somebody knows why, tell me too. OK, these Debian bug reports might be relevant: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=128918&repeatmerged=yes "Each time Esetroot runs the memory usage taken up by the Xserver increases by 7MB." and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97104&repeatmerged=yes "I've tracked down the memory leak cause. Whenever a background is changed in KDE, 4 more MB are leaked in X. When setting up changing backgrounds in KDE, this causes an increasing X server." So, it looks like this might not be my fault :-) The double buffering seems to rapidly create and destroy a large number of pixmaps; perhaps this triggers a bug in XFree86? -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |