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 725146 - Criticals from menu code
Criticals from menu code
Status: RESOLVED DUPLICATE of bug 788163
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 725142
 
 
Reported: 2014-02-25 13:48 UTC by Morten Welinder
Modified: 2017-10-09 11:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Test program (1.64 KB, text/plain)
2014-02-25 13:48 UTC, Morten Welinder 		  Details
Proposed patch (612 bytes, patch)
2014-02-25 14:27 UTC, Jean Bréfort 		none Details | Review

Description Morten Welinder 2014-02-25 13:48:08 UTC 
Created attachment 270273 [details]
Test program

With the upcoming test program, selecting Moo->Baa produces...

(a.out:9711): Gtk-CRITICAL **: gtk_window_set_attached_to: assertion `GTK_IS_WINDOW (window)' failed

Similar code to this further produces ref-count errors on my home machine
which has a newer gtk+.  I will test this particular piece of code on that
machine later.

The problem only occurs for menu entries in a submenu.  When "Baa" is moved
to the top-level menu I see no problem.
Comment 1 Jean Bréfort 2014-02-25 14:27:51 UTC 
Created attachment 270278 [details] [review]
Proposed patch

There are other uses of this pointer without testing that might fire a critical.
Comment 2 Matthias Clasen 2014-03-03 22:26:21 UTC 
What are you trying to achieve ? Is the intention really to destroy the submenu ?
Comment 3 Morten Welinder 2014-03-04 04:06:21 UTC 
> Is the intention really to destroy the submenu?

Yes.  It's a single-use context menu.
Comment 4 Matthias Clasen 2014-03-13 04:25:12 UTC 
but presumably you want to destroy the entire menu, not just the submenu that happens to contain the activated item ?
Comment 5 Morten Welinder 2014-03-13 15:04:16 UTC 
Sorry, I misread your question in comment 2.

The intention is to get rid of the entire menu.
Comment 6 Matthias Clasen 2014-03-13 15:33:01 UTC 
the callback doesn't do that, though. The toplevel it finds is the submenu - each menu is its own toplevel. Admittedly, the menu could should probably be safe against this sort of thing, by detaching on destroy.
Comment 7 Daniel Boles 2017-10-09 11:34:53 UTC 

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