Bug 645483 - GtkToolItem's handling of ->priv->menu_item
GtkToolItem's handling of ->priv->menu_item
Status: NEW
Product: gtk+
Classification: Platform
Component: Widget: GtkToolbar
2.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-03-22 01:20 UTC by Morten Welinder
Modified: 2012-03-17 23:59 UTC (History)
1 user (show)

See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch with debug code (2.36 KB, patch)
2011-04-06 23:43 UTC, Morten Welinder 		none Details | Diff | Review
View All Add an attachment (proposed patch, testcase, etc.)

Description Morten Welinder 2011-03-22 01:20:08 UTC 
->priv->menu_item is a GtkWidget created by gtk_action_create_menu_item.
It should not be assumed to have and keep a ref-count of 1.

Therefore, it should be explicitly destroyed by gtk_tool_item_dispose
and, perhaps, gtk_tool_item_set_proxy_menu_item.

Relatedly, the current contents of gtk_tool_item_finalize seems to be
more appropriate for gtk_tool_item_dispose.  (But then the items need
to be zeroed.)
Comment 1 Morten Welinder 2011-03-26 00:36:40 UTC 
I should add that Gtk+ is perfectly capable of supplying that second ref
all by itself.  I.e., whenever an overflow menu item is created, it is leaked.
This didn't use to be the case.

The extra ref seems to be set deep down in gtk_accel_label_set_accel_widget,
unless I'm mistaken.
Comment 2 Morten Welinder 2011-04-06 23:37:13 UTC 
It's a case of circular links:

GtkMenuItem holds a ref to its child, a GtkAccelLabel.
The GtkAccelLabel holds a ref to the GtkMenuItem as its "accel widget".

Something needs to break those links.  The upcoming patch works for me.
Note: contain debug code.

Offline CC-ing jpetersen@openismus.com who appears to have refactored
GtkMenuItem to create the ref loop.
Comment 3 Morten Welinder 2011-04-06 23:43:49 UTC 
Created attachment 185376 [details] [review]
Patch with debug code
Note You need to log in before you can comment on or make changes to this bug.