GNOME Bugzilla – Bug 737581
Crash with switching workspace on dual screen configuration
Last modified: 2014-09-30 10:02:14 UTC
I get fairly regular crash when switching workspaces on my dual screen workstation. Not sure what actually triggers the crashes... Here is the backtrace from the C side :
+ Trace 234142
Thread 1 (Thread 0x7fbcbd68fac0 (LWP 6474))
A debugging session is active. Here is the backtrace from the JS side : == Stack trace for context 0x38301c0 == WorkspaceThumbnail<.activate@resource:///org/gnome/shell/ui/workspaceThumbnail.js:551 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 ThumbnailsBox<._onButtonRelease@resource:///org/gnome/shell/ui/workspaceThumbnail.js:683 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 == Stack trace for context 0x38301c0 == WorkspaceThumbnail<.activate@resource:///org/gnome/shell/ui/workspaceThumbnail.js:551 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 ThumbnailsBox<._onButtonRelease@resource:///org/gnome/shell/ui/workspaceThumbnail.js:683 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 == Stack trace for context 0x38301c0 == WorkspaceThumbnail<.activate@resource:///org/gnome/shell/ui/workspaceThumbnail.js:551 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 ThumbnailsBox<._onButtonRelease@resource:///org/gnome/shell/ui/workspaceThumbnail.js:683 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 /usr/lib/libgjs.so.0(gjs_print_backtrace+0x31)[0x7fbcbc9ca841] [0x7fff624255bf]
Seems to be related to #737577
Can you try git master after Florian's workspace fixes?
*** Bug 737577 has been marked as a duplicate of this bug. ***
Recompiled master with all patches from https://git.gnome.org/browse/mutter/commit/?id=2eec11b4453ecefd963385b810ea8daf330b7d22 and it still crashes. I'm getting better at getting it to crash now, here are the steps : 1. Close all windows 2. Open a window on the main screen on first workspace 3. Open a window on the second screen 4. Open overview and click on last workspace (the second one, it should be empty) 5. Open a new window on the main screen 6. Open overview and click on the last workspace (the third one, it should be empty) => assert/crash
OK. I don't have a second screen to test with right now. Florian, can you take a look at this one? I can't think of any reason this would happen -- the window should be in the MRU list for all workspaces if it's sticky.
Hi, I can reproduce this bug in Debian Sid with GNOME 3.14.0 Log from journalctl: Sep 29 16:54:01 arrayan gnome-session[1424]: ** Sep 29 16:54:01 arrayan gnome-session[1424]: mutter:ERROR:core/window.c:4725:meta_window_set_focused_internal: assertion failed: (link) Sep 29 16:54:01 arrayan gnome-session[1424]: gnome-session[1424]: WARNING: Application 'gnome-shell.desktop' killed by signal 6
Created attachment 287400 [details] [review] workspace: Correctly initialize MRU list The workspace MRU lists are updated when windows are managed/unmanaged or change workspaces. However those updates obviously only apply to existing workspaces - new workspaces will always start out with an empty MRU list, despite sticky windows already being "on" that workspace. As we now assert that the list contains all windows located on the workspace, we need to initialize it correctly to avoid a crash.
(In reply to comment #5) > OK. I don't have a second screen to test with right now. Here's a reproducer which does not require a second screen: (1) make a window sticky (2) trigger creation of a new workspace (3) switch to the new workspace
Review of attachment 287400 [details] [review]: ::: src/core/workspace.c @@ +182,3 @@ + /* make sure sticky windows are in our mru_list */ + windows = meta_display_list_windows (screen->display, META_LIST_DEFAULT); You leak this. I'm also not sure it's sorted correctly (it's just a ptrcmp), but I'm not sure what the correct initial sort should be.
Created attachment 287401 [details] [review] display: Optionally sort window list
Created attachment 287402 [details] [review] workspace: Correctly initialize MRU list The workspace MRU lists are updated when windows are managed/unmanaged or change workspaces. However those updates obviously only apply to existing workspaces - new workspaces will always start out with an empty MRU list, despite sticky windows already being "on" that workspace. As we now assert that the list contains all windows located on the workspace, we need to initialize it correctly to avoid a crash.
Review of attachment 287401 [details] [review]: Clever. I like it.
Review of attachment 287402 [details] [review]: OK.
Attachment 287401 [details] pushed as 9f8b641 - display: Optionally sort window list Attachment 287402 [details] pushed as 4f3de2c - workspace: Correctly initialize MRU list
Compil with 2 previous patch doesn't fix the issue: sept. 30 09:14:45 arch gnome-session[424]: mutter:ERROR:core/window.c:4725:meta_window_set_focused_internal: assertion failed: (link) sept. 30 09:14:46 arch gnome-session[424]: gnome-session[424]: WARNING: Application 'gnome-shell.desktop' killed by signal 6 sept. 30 09:14:46 arch gnome-session[424]: WARNING: Application 'gnome-shell.desktop' killed by signal 6 It happens when closing a tab in firefox (maximised on second screen) Maybe another bug? https://bugzilla.gnome.org/show_bug.cgi?id=737577
Recompiled with the all the patches from master seems to fix my problem here. Thanks a lot.