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 681399 - crash when creating a new workspace by moving a window in between two existing ones
crash when creating a new workspace by moving a window in between two existin...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.4.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
3.6.1
: 684074 686011 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-08-07 19:03 UTC by Benjamin Berg
Modified: 2012-10-12 07:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GActionMuxer: always disconnect handlers from GDBusActionGroup (1.19 KB, patch)
2012-09-30 18:06 UTC, Pavel Vasin
reviewed Details | Review
GActionMuxer: disconnect group signals on finalize (1.49 KB, patch)
2012-10-04 08:36 UTC, Pavel Vasin
committed Details | Review

Description Benjamin Berg 2012-08-07 19:03:43 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
Comment 1 Benjamin Berg 2012-09-15 09:56:18 UTC
*** Bug 684074 has been marked as a duplicate of this bug. ***
Comment 2 Benjamin Berg 2012-09-15 09:59:15 UTC
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.
Comment 3 Florian Müllner 2012-09-25 15:13:44 UTC
(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
Comment 4 Pavel Vasin 2012-09-30 13:53:47 UTC
Definitely it is #679509
Comment 5 Pavel Vasin 2012-09-30 18:06:24 UTC
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...
Comment 6 Florian Müllner 2012-10-03 17:12:07 UTC
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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-10-03 17:16:19 UTC
Review of attachment 225433 [details] [review]:

We also should coordinate this fix to the other users of gactionmuxer: GTK+ is one.
Comment 8 Pavel Vasin 2012-10-04 05:09:01 UTC
(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
Comment 9 Florian Müllner 2012-10-04 06:31:53 UTC
Did you intend to attach an updated patch?
Comment 10 Pavel Vasin 2012-10-04 08:36:02 UTC
Created attachment 225776 [details] [review]
GActionMuxer: disconnect group signals on finalize

cherry-picked from GTK+
Comment 11 Florian Müllner 2012-10-04 10:05:21 UTC
Comment on attachment 225776 [details] [review]
GActionMuxer: disconnect group signals on finalize

Sure, that's fine as well ...
Comment 12 Florian Müllner 2012-10-04 10:05:52 UTC
Attachment 225776 [details] pushed as 1118ec9 - GActionMuxer: disconnect group signals on finalize
Comment 13 Florian Müllner 2012-10-12 07:53:53 UTC
*** Bug 686011 has been marked as a duplicate of this bug. ***