After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684843 - Memory leaks in GtkSpinner
Memory leaks in GtkSpinner
Status: RESOLVED DUPLICATE of bug 683246
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.24.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-09-26 02:28 UTC by Michael Egorov
Modified: 2012-09-26 07:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Egorov 2012-09-26 02:28:55 UTC
GTK Spinners leak memory when spinning and visible. If you hide the widget, or
stop it spinning, the memory usage does not go up, but it does not reset
either. Memory usage will continue to climb once you start it visibly spinning
again. It also leaks when behind another window (for instance a terminal).

Minimalistic example:
--
import gtk
window = gtk.Window()
spinner = gtk.Spinner()
window.add(spinner)
spinner.start()
window.show_all()
gtk.main()
--

Run the example and watch the python process memory usage climb up by a few Kb
per second. It isn't a very quick leak, but anything that relies on GTK
Spinners will crash after several days once the memory usage gets too high. One
example (of many) is Glade, with a visible spinner, left open over a weekend,
will result in a crash by the time you come in on Monday morning. 

This bug makes it difficult to have long running, robust programs.

This bug is a copy of the bug #683246, however I believe it affects not only pygtk. Can anyone test that properly?
Comment 1 André Klapper 2012-09-26 07:54:52 UTC
Please avoid creating exact copies of existing reports but add comments to the existing report instead. 
Could you please create a C test program, or test it with PyGObject (as PyGtk is deprecated)?

*** This bug has been marked as a duplicate of bug 683246 ***