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 91404 - Gtk::Button: memory leak when using mnemonic=true.
Gtk::Button: memory leak when using mnemonic=true.
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
2.0
Other Solaris
: Normal minor
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2002-08-22 12:24 UTC by Michael v. Szombathely
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the test case as described (953 bytes, text/plain)
2002-08-22 12:31 UTC, Michael v. Szombathely
Details
main.cc (GTK+ C test) (949 bytes, text/plain)
2002-08-26 14:45 UTC, Murray Cumming
Details

Description Michael v. Szombathely 2002-08-22 12:24:07 UTC
We have detected that with the newer version of gtkmm (1.3.20+) the
destructors of mangaged C++ wrapper objects never get called.

This happens, because Gtk::Object::destroy_notify is not call for managed
objects.
Comment 1 Michael v. Szombathely 2002-08-22 12:31:01 UTC
Created attachment 10642 [details]
the test case as described
Comment 2 Murray Cumming 2002-08-22 17:30:42 UTC
Have you tested this with 1.3.21?
Comment 3 Michael v. Szombathely 2002-08-22 19:42:59 UTC
Yes, it happens with gtkmm-1.3.21 too, both g++ and Forte C++.
Comment 4 Murray Cumming 2002-08-24 15:01:30 UTC
I have added a corrected version of this test in
tests/child_widget_managed.

I believe that the problem is that you are calling Gtk::Main::quit()
at an inappropriate time. The corrected test code shows how this
should be done, using the Gtk::Main::run(window) overload.

If you believe that this should work, then you should investigate
whether the GtkButton or GtkWindow are actually destroyed. It might
help to turn on the debugging messages in glib/glibmm/debug.h
Comment 5 Michael v. Szombathely 2002-08-26 12:26:21 UTC
Well, the use of hide() instead of quit() is okay.

But the observed problem in this case comes from Gtk::Button. If we
replace in tests/child_widget_managed/main.cc

	MyButton::MyButton()
	: Gtk::Button("Ok")
	{ }

by

	MyButton::MyButton()
	: Gtk::Button("_Ok", true)
	{ }

then the destructor of Gtk::Button ist not called no matter we call
hide() or quit() to leave the main loop. There seems to be a
registration problem with Gtk::Button, when mnemonic is activated.
Comment 6 Murray Cumming 2002-08-26 14:44:31 UTC
This doesn't seem to be a bug in GTK+, as shown by this C test code.
Comment 7 Murray Cumming 2002-08-26 14:45:32 UTC
Created attachment 10714 [details]
main.cc (GTK+ C test)
Comment 8 Murray Cumming 2002-09-15 16:45:04 UTC
This feels like a radical change, but everything seems to work:

2002-09-15  Murray Cumming  <murrayc@usa.net>

	* gtk/src/container.ccg: Container_Class::destroy_callback(): We
	don't remove child widgets if they are not manage()ed, so that
	gtk_container_destroy will call destroy them
	properly. gtk_widget_destroy() will always succeed, but
	gtk_container_remove() isn't guarranteed to cause destruction.
	It is now clear that this callback was necessary, not just as a
	refcount hack - we really do need to remove non-manage()ed
	widgets, because SINKing them does not prevent them from being
	destroyed in gtk_container_destroy().
Comment 9 Murray Cumming 2003-06-25 09:59:08 UTC
I don't think so. The whole point of that code is explained in the 
comment at the start of the method:
// We need to remove non-manage()ed widgets to prevent 
gtk_container_destroy() from destroying them.
// Contary to what we thought once, even non-floating (sunk) widgets 
are destroyed by gtk_container_destroy()

It should have no effect on manage()s widgets.
Comment 10 Murray Cumming 2003-06-25 09:59:34 UTC
Sorry, ignore that. Wrong bug.