GNOME Bugzilla – Bug 681399
crash when creating a new workspace by moving a window in between two existing ones
Last modified: 2012-10-12 07:53:53 UTC
I have the following setup: * external (larger) screen to the left * internal screen on the right side (aligned to the bottom) * "Workspace only on primary monitor" OFF * the external/left screen is the primary screen This seems to only happen if the external monitor is plugged in. Steps to reproduce: 1. go into overview mode 2. select a window 3. drop between two workspaces to create a new workspace Result: Crash I am currently running debian unstable with GNOME 3.4.2. The .xsession-errors says: (gnome-shell:27725): Clutter-WARNING **: clutter_actor_raise Actor 'ClutterGroup' is not in the same container as actor 'ClutterGroup' JS ERROR: !!! Exception was: TypeError: this._workspaces[w] is undefined JS ERROR: !!! lineNumber = '313' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/workspacesView.js"' JS ERROR: !!! stack = '"(4,5)@/usr/share/gnome-shell/js/ui/workspacesView.js:313 wrapper(4,5)@/usr/share/gjs-1.0/lang.js:204 ([object _private_Meta_Screen],[object _private_GObject_ParamSpec])@/usr/share/gnome-shell/js/ui/workspacesView.js:990 wrapper([object _private_Meta_Screen],[object _private_GObject_ParamSpec])@/usr/share/gjs-1.0/lang.js:204 _checkWorkspaces()@/usr/share/gnome-shell/js/ui/main.js:332 "' JS ERROR: !!! message = '"this._workspaces[w] is undefined"' ** GLib-GIO:ERROR:/home/martin/debian/pkg-gnome/build-area/glib2.0-2.33.1/./gio/gdbusactiongroup.c:252:g_dbus_action_group_describe_all_done: assertion failed: (group->connection == (gpointer) source) gnome-session[27617]: WARNING: Application 'gnome-shell.desktop' killed by signal 6
*** Bug 684074 has been marked as a duplicate of this bug. ***
OK, seems like I am unable to check my own bugs before creating duplicate reports ... :-) An important new information is that this *only happens with epiphany* for me. Also a multi monitor setup is not required to reproduce this. Maybe someone else is able to reproduce this with this new information.
(In reply to comment #2) > An important new information is that this *only happens with epiphany* for me. s/epiphany/any application that is providing an application menu/ Given that more and more applications do support the app menu, we should try to track this down for 3.6.1
Definitely it is #679509
Created attachment 225433 [details] [review] GActionMuxer: always disconnect handlers from GDBusActionGroup (In reply to comment #4) As my patch for glib was rejected, signal handlers should be disconnected, maybe like that...
Review of attachment 225433 [details] [review]: The code looks fine, but it's not immediately obvious, so the patch should have a more verbose commit message, e.g. something like Currently handlers are only disconnected when a GDBusActionGroup is removed explicitly via g_action_muxer_remove(), but not when a group is destroyed implicitly via the GHashTable value_destroy_func. Move the code in question to always disconnect signal handlers on group destruction, which fixes a crash when calling a handler on a destroyed group.
Review of attachment 225433 [details] [review]: We also should coordinate this fix to the other users of gactionmuxer: GTK+ is one.
(In reply to comment #7) > We also should coordinate this fix to the other users of gactionmuxer: GTK+ is > one. Already fixed in GTK+, commit 6e11c3106a5661c172f2056f9da147c72708fafe
Did you intend to attach an updated patch?
Created attachment 225776 [details] [review] GActionMuxer: disconnect group signals on finalize cherry-picked from GTK+
Comment on attachment 225776 [details] [review] GActionMuxer: disconnect group signals on finalize Sure, that's fine as well ...
Attachment 225776 [details] pushed as 1118ec9 - GActionMuxer: disconnect group signals on finalize
*** Bug 686011 has been marked as a duplicate of this bug. ***