GNOME Bugzilla – Bug 755407
Gtk-CRITICAL gtk_container_foreach: assertion 'GTK_IS_CONTAINER (container)' failed
Last modified: 2015-12-12 21:26:16 UTC
(meld:14206): Gtk-CRITICAL **: gtk_container_foreach: assertion 'GTK_IS_CONTAINER (container)' failed Fedora 22 meld-3.14.0-1.fc22.noarch pygtk2-2.24.0-11.fc22.x86_64 python-2.7.10-4.fc22.x86_64
Also reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1272734
Can you provide a stacktrace ?
(In reply to Matthias Clasen from comment #2) > Can you provide a stacktrace ? Sure but please tell me how to generate it. gdb and strace are probably not what you need?
USe t a a bt in gdb, please
ok "bt" I know, also how to attach to a process but with "t a a" I am not familiar with. gdb python /usr/bin/meld ... "/usr/bin/meld" is not a core dump: File format not recognized ... also this doesn't enlight me... https://wiki.python.org/moin/DebuggingWithGdb I'm afraid to need further/more detailed instructions.
I am having the exact same problem on ubuntu at home. Same issue on centOs office machine at work. Just entering meld re-creates the problem
I have investigated the issue and fixed it. here is my pull request https://github.com/GNOME/meld/pull/7
(In reply to Zain from comment #7) > I have investigated the issue and fixed it. > > here is my pull request https://github.com/GNOME/meld/pull/7 I patched locally the file /usr/lib/python2.7/site-packages/meld/meldapp.py in my Fedora 22 box and the bug is gone. Excellent, thanks!
(In reply to Zain from comment #7) > I have investigated the issue and fixed it. > > here is my pull request https://github.com/GNOME/meld/pull/7 Thanks for that. Unfortunately this doesn't actually fix the problem, but just hides it. When I get a minute I'll apply your patch anyway, since it's a definite improvement and means that most users won't ever see the logs. It's still easy to reproduce the bug by starting two Meld instances from the command line (which will end up as a single instance, etc.) and exiting the second one using the window close button. It's also worth noting that even without the patch, the problem *doesn't* show up if all tabs are closed before closing Meld with the window close button.
Created attachment 315092 [details] Stacktrace (In reply to Matthias Clasen from comment #2) > Can you provide a stacktrace ? Attached. The logs are coming from GtkUIManager doing idle updates. At this point I'm happy to believe either that this is a regression in GtkUIManager, or that Meld is hanging on to a reference too long somewhere. However, the difference between the two test cases in terms of lines of python code hit is tiny, and I haven't found anything that we're obviously doing wrong. It's worth mentioning that Meld has only been using GTK+ 3 for about a 18 months, so I also wouldn't bet against this being a 2 -> 3 change.
*** Bug 756225 has been marked as a duplicate of this bug. ***
This is now fixed, I hope, in master. When closing a window, we first close all tabs. This queues GtkUIManager updates to the window tab list. However, by the time the GtkUIManager idle update ticks around, the window and its associated menu, etc. no longer exist. The commits just clean up some of our GtkUIManager state handling, and call ensure_update() to make sure everything has settled at points where it might matter.