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 591003 - Memory Leak in Gtk::Window
Memory Leak in Gtk::Window
Status: RESOLVED DUPLICATE of bug 533456
Product: gtkmm
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal blocker
: ---
Assigned To: gtkmm-forge
gtkmm-forge
: 591000 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-08-06 21:25 UTC by Phoenix
Modified: 2009-08-07 09:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Phoenix 2009-08-06 21:25:58 UTC
Creating and destroying a Gtk::Window in a loop loses 3MB on each iteration as demonstrated by this tiny program. Since creating windows is a fundamental requirement in our application, this is depleting all of memory and swap, and finally crashing.




#include <gtkmm.h>
#include <iostream>

using namespace std;


class Win : public Gtk::Window
{
public:
	Win()
	{
		set_size_request(1024, 768);
		realize();
	}

	~Win()
	{
		cerr << "Destroying window" << endl;
	}
};



int
main(int argc, char* argv[])
{
	Gtk::Main App(argc, argv);			// Initialize GTK+

	while (true) {
		Win* w = new Win;
		if (Gtk::Main::events_pending())
			Gtk::Main::iteration();
		::sleep(2);
		delete w;
	}

	exit (0);
}
Comment 1 Phoenix 2009-08-06 22:00:36 UTC
*** Bug 591000 has been marked as a duplicate of this bug. ***
Comment 2 Hammered 2009-08-07 05:57:58 UTC
I've let it run for 20~30 iterations and the memory usage always was 2.3MB. It never fluctuated. What version of gtkmm are you using?

I am using 2.16 on Ubuntu 9.04 amd64.
Comment 3 Phoenix 2009-08-07 07:01:21 UTC
I am running version 2.12 on a 32-bit Fedora FC9 on x86 using DirectFB 1.1.1
I have a suspicion that the leak is in the DirectFB back-end.
Comment 4 Phoenix 2009-08-07 09:52:49 UTC
Yep - this turns out to be a problem in the DirectFB back-end.
bug #533456 addresses this.
Comment 5 Phoenix 2009-08-07 09:53:38 UTC

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