GNOME Bugzilla – Bug 79720
Memory leak in Win32 GTK+ version
Last modified: 2011-02-04 16:11:52 UTC
Richard Warren's mail to the gimpwin-dev list: The simple test-program below creates a label and changes the text in it repeatedly. It seems to eat memory at a rate of about 8kbytes/sec until it dies. I'm using the Win32 2002-03-14 version of GTK+ V2 from Tor's website. The problem doesn't happen on Linux with V2.0.0 (but used to happen with V1.3.9). Interestingly, when the program is minimised and then opened up again it seems to free a lot of the memory, but I can't force my users to do that periodically unfortunately. Does anybody have any suggestions of how I can fix/avoid this please? I'm starting to get a bit desperate.
Created attachment 7908 [details] Test program
Relate to? Tue Feb 5 19:13:42 2002 Owen Taylor <otaylor@redhat.com> * gdk/x11/gdkgeometry-x11.c (gdk_window_queue): Keep the length of the anti-expose queue finite, by if it gets too long, first doing a XSync() and checking the event queue, and if that doesn't work, simply discarding all anti-expose items in the queue. I'm not sure that it makes sense for the win32 port to have an anti-expose queue at all, but if it does, it probably needs a similar fix.
BTW, in _gdk_window_process_expose(), should the queue_delete_link (translate_queue, translate_queue->head); be queue_delete_link (translate_queue, the queue item being handled); ? Or at least, maybe some comment about what's happening would be helpful... Is there an assumption here about the ordering of items in serial order or something?
the items in the queue have item->serial always non-decreasing, (new items are appended to the queue, and the result of NextRequest increases) so once if (serial < item->serial) fails, it will always fails. In other words, the deleted items are always at the beginning of the queue so the code works fine. I guess NextRequest would wrap around after GTK+ makes 4 billion X calls... perhaps this code needs to deal with that, since it will blow up badly when that happens... and it's not inconceivable an app might make thousands of drawing calls a second for several months. But other than that that, it's fine.
Created attachment 10367 [details] small example that leaks memory in gtk_widget_queue_draw
Tentative fix (by Florent Duquet) applied to gtk-2-0.
Same fix applied to HEAD, too.
translate_queue concept now removed from Win32 backend in both HEAD and gtk-2-0, as part of work on screen update bugs that were most visible in scrolling in testgtk and gtk-demo. The test programs no longer leak memory.