Description of problem: Trying to connect to a Cisco VPN Version-Release number of selected component: gnome-shell-3.30.2-1.fc29 Additional info: reporter: libreport-2.9.6 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=2d3a3393623b482d9b07e9595589edad;i=4e548;b=5097b1145e3f47129015390215f9b67d;m=420c7e72d;t=57ba7fe1d2a29;x=788a868b0c8500f9 kernel: 4.19.3-300.fc29.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 0 (6 frames) #0 shell_app_dispose at ../src/shell-app.c:1485 #2 g_hash_table_remove_node at ghash.c:459 #3 g_hash_table_remove_internal at ghash.c:1376 #4 _shell_app_system_notify_app_state_changed at ../src/shell-app-system.c:375 #5 shell_app_state_transition at ../src/shell-app.c:901 #6 _shell_app_remove_window at ../src/shell-app.c:1110 Potential duplicate: bug 1067704
Created attachment 1509588 [details] File: backtrace
Created attachment 1509589 [details] File: cgroup
Created attachment 1509590 [details] File: core_backtrace
Created attachment 1509591 [details] File: cpuinfo
Created attachment 1509592 [details] File: dso_list
Created attachment 1509593 [details] File: environ
Created attachment 1509594 [details] File: exploitable
Created attachment 1509595 [details] File: limits
Created attachment 1509596 [details] File: maps
Created attachment 1509597 [details] File: mountinfo
Created attachment 1509598 [details] File: open_fds
Created attachment 1509599 [details] File: proc_pid_status
Created attachment 1509600 [details] File: var_log_messages
Same happened here after a closing a "overwrite this file ?" dialog from LibreOffice.
Hmm and it seems to be reliably reproducible here, running the same procedure makes Gnome Shell crash again: 1. Open LibreOffice calc 2. Go to File → Print and in the list of printers choose "print to file" 3. In the list of file formats, pick PDF (probably irrelevant ?) 4. Select an existing PDF file to replace, press "Print" 5. A dialog "The file will be overwritten appears", click "Yes" 6. Boom :-)
(sorry for the spam) this actually also happens without overwriting a file, so the "problematic" window would be the file picker and not the confirmation dialog. It turns out I had enabled the "experimental features" of LibreOffice, disabling that seems to fix the issue (even though the UI looks strictly the same).
*** Bug 1657198 has been marked as a duplicate of this bug. ***
Similar problem has been detected: unpacking a large RAR file in gnome files reporter: libreport-2.9.7 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=46d14ec7c8444305b65fcd1666885f70;i=a53fb5;b=d5e3a0ee5ee540d4a3c5f278d120ff41;m=65467e8e9;t=57e12c48800bc;x=b7c9bf7d1eb41566 kernel: 4.19.10-300.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Was just about to burn a DVD via burn:// in Nautilus. Clicked Burn button, shell hung then crashed. reporter: libreport-2.9.7 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=e948043895694ed2bffa867c150a0622;i=7c0ccb;b=b72a644802f04eb687c8628887ae41be;m=352c7d9720;t=57e623f59b29a;x=2c657d6e5075d57e kernel: 4.19.10-300.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 500
It appears my issue is reproducible - tried the same again, with the same result.
Similar problem has been detected: I was working with Kexi creating a file for a project and it failed when I cancel the file selecction reporter: libreport-2.9.7 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=e36b0705020b4d9791ccfa45fa6c43e5;i=63b2c;b=76dac49b02264eda8ded4e8866beddc6;m=aad40fe09;t=57fdb3db95220;x=b3528592969b1d16 kernel: 4.19.15-300.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Cancelling the Printing dialog in Evolution reporter: libreport-2.9.7 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=bbc12581ef234c08b7e9dadb5ad3ef30;i=154706;b=2ceeb03c9de447659ba8f5e9d56bc8a8;m=40afd342a6;t=5800be89e3048;x=210052528aad55b9 kernel: 4.19.15-300.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: How to reproduce: 1. Download psensor sources from: http://wpitchoune.net/psensor/files/psensor-1.1.5.tar.gz 2. Compile and install (./configure && make && make install) 3. Run GNOME Shell in Wayland mode 4. Run psensor 5. Open preferences 6. Change for example graph update interval and click OK What happens: Whole GNOME Shell crashes and all open GUI applications are gone! Note: Sometimes it does not crash the first time and I have to open and close the prefrences multiple times. Try to close them using the cross icon in the right upper corner too. What should happen: If the psensor application is buggy it can crash. I would even accept if GNOME Shell crashed for some reason and restarted itself as it does in the X11 mode. But it is totally unacceptable that one app crashes and takes down all the other GUI apps as well! Note: I cannot reproduce the crash when running GNOME Shell in X11 mode. reporter: libreport-2.9.7 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=abf13b3c3c4848aea3f95e68ae9e9663;i=29910;b=451221665d8440c9b619e2bef8ac34d9;m=dbcf9023;t=58047e9d3a7cc;x=315a356b4b21ac9f kernel: 4.20.3-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 500
*** Bug 1669828 has been marked as a duplicate of this bug. ***
*** Bug 1672746 has been marked as a duplicate of this bug. ***
*** Bug 1677752 has been marked as a duplicate of this bug. ***
Similar problem has been detected: 1. Disconnected from Wi-Fi which in turn disconnected me from VPN 2. Connected to Wi-Fi again 3. Tried to connect to VPN again using the VPN menu in the top panel 4. Entered the password What happened: The whole graphical session crashed (including all apps!). What should happen: I should be connected to VPN. Or it could display an error message or whatever but in no way crash all the apps! Notes: The crash happened even when I tried to close the VPN connection dialog instead of entering the password. Rant: Who came up with the idea that it would super cool to make a desktop environment that crashes everynow and then and force-closes all the running apps during the crash? reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=217c3a1e66f743a2bd2be4cf3d5047fe;i=1d7494;b=cb2d8ddec09c41a5b11a557529ff0d6d;m=16cd7d6900;t=582dfdabac8d2;x=74f082eaa9ddfe4f kernel: 4.20.10-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 500
It seemed to me that there was no progress in fixing the issues so I tried to debug it by myself. I found that the SIGSEGV is caused by `app->running_state->windows` being NULL here: https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1485 I looked for the places where the `running_state->windows` linked list is modified and found that it is always initialized along with the `running_state` in `_shell_app_add_window()` here: https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1076 That means that `running_state` is never created with empty `windows`. Items are removed from `running_state->windows` only in `_shell_app_remove_window()` function (see https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1106 ) that sets `app->running_state` to NULL when there is no remaining window left (see https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1113 ). So I was really confused how we can get into such situation that `app->running_state` is not NULL but `app->running_state->windows` is NULL (i.e. empty linked list). Then I looked more carefully on the backtrace: #0 0x00007f76bba85467 in shell_app_dispose (object=0x5646f41965c0) at ../src/shell-app.c:1485 #1 0x00007f76bb8248c8 in g_object_unref () at /lib64/libgobject-2.0.so.0 #2 0x00007f76bb72a505 in () at /lib64/libglib-2.0.so.0 #3 0x00007f76bb72ae3e in () at /lib64/libglib-2.0.so.0 #4 0x00007f76bba866cf in _shell_app_system_notify_app_state_changed (self=0x5646f0fec360, app=0x5646f41965c0) at ../src/shell-app-system.c:375 #5 0x00007f76bba84008 in shell_app_state_transition (app=0x5646f41965c0, state=<optimized out>) at ../src/shell-app.c:901 #6 0x00007f76bba8529f in _shell_app_remove_window (window=0x5646f3e102e0, app=0x5646f41965c0) at ../src/shell-app.c:1110 #7 0x00007f76bba8529f in _shell_app_remove_window (app=0x5646f41965c0, window=0x5646f3e102e0) at ../src/shell-app.c:1094 I suppose that at #7 we are in a state when there is the last window in the app that we want to remove. The `_shell_app_remove_window()` function (#7), after removing the window from the `windows` linked list, calls `shell_app_sync_running_state()` (#6) which in turn calls `shell_app_state_transition()` (#5) that calls `_shell_app_system_notify_app_state_changed()` which causes the `app` to be disposed by `shell_app_dispose()` and this is the point where we are trying to call `_shell_app_remove_window()` again (is it correct to use the term recursion here?) but now with `app->running_state` that was not yet set to NULL by the parent `_shell_app_remove_window()` call and `app->running_state->windows` equal to NULL. So the problematic part is this line: https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1110 that causes the `shell_app_dispose()` to be called before `app->running_state` is set to NULL here: https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1113 . What would be the proper solution to this issue? a) Should we call `shell_app_sync_running_state()` after the `app->running_state` is destroyed and set to NULL? b) Should we check whether `app->running_state->windows` is non-NULL in the while condition in `shell_app_dispose()` ( https://github.com/GNOME/gnome-shell/blob/3.30.2/src/shell-app.c#L1484 ) ? Notice, that there used to be a version of the code that basically did the check: https://github.com/GNOME/gnome-shell/commit/36c69124f749c48f583e8ff2413d27e10d1229e0 They changed the code to fix a crash in the same scenario (removing the last window) but the problem was that during removing the last window, `app->running_state` got destroyed and set to NULL so the while loop checking `app->running_state->windows` caused the crash. I am not even sure whether it is right that removing the last window triggers `shell_app_dispose()` and that `shell_app_dispose()` tries to remove all windows. If it is designed behaviour then I guess that `shell_app_dispose()` should not rely on the fact that non-NULL `app->running_state` always has non-NULL `app->running_state->windows`. That would mean that fix b) is the right one.
I have just found a related issue in the GNOME Shell GitLab project: https://gitlab.gnome.org/GNOME/gnome-shell/issues/822 This comment in a duplicate issue does a pretty good job in describing the problem: https://gitlab.gnome.org/GNOME/gnome-shell/issues/918#note_413502
This bug looks like a duplicate: https://bugzilla.redhat.com/show_bug.cgi?id=1639046
*** Bug 1683851 has been marked as a duplicate of this bug. ***
Important note: I am only able to reproduce the issue when using two displays in side-by-side mode (internal laptop screen 1366x768 and external HDMI screen 1920x1080 that is set as primary).
(In reply to Miroslav Šustek from comment #32) > Important note: I am only able to reproduce the issue when using two > displays in side-by-side mode (internal laptop screen 1366x768 and external > HDMI screen 1920x1080 that is set as primary). Now that you say it, I think it only happened to me at work where I have dual screen, and I do use Cisco VPN from home (without dual screen) from time to time
Similar problem has been detected: Drafting new email in evolution, inserting an image. Keeps happening randomly when the image to insert is chosen, maybe once every 10-15 times this action is performed. reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=464bd60d37fa42efae9e9145da1f42d0;i=113e698;b=b3b640f77d06435688c50154a0fccaf1;m=971619d29;t=582f74ed9fe8b;x=1b920af9efaae61 kernel: 4.20.10-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1001
*** Bug 1689871 has been marked as a duplicate of this bug. ***
*** Bug 1690375 has been marked as a duplicate of this bug. ***
*** Bug 1692432 has been marked as a duplicate of this bug. ***
*** Bug 1692894 has been marked as a duplicate of this bug. ***
I'm getting the error using VidCutter. I'm attempting to trim a video, from its src, which is a writable usb stick, located on /dev/sda1 (vfat format), and attempted to write the file to /tmp/. In attempting to re-create error, I haven't succeeded yet, will keep attempting to cause the error condition.
*** Bug 1693528 has been marked as a duplicate of this bug. ***
*** Bug 1697471 has been marked as a duplicate of this bug. ***
*** Bug 1700330 has been marked as a duplicate of this bug. ***
I've read the comments here and my bug 1700330 probably also happens only when in dual-screen, I am going to watch this.
*** Bug 1700479 has been marked as a duplicate of this bug. ***
My gnome-shell just crashed with a single display so this or bug 1700330 is not limited to dual-screen. And it was Eclipse again.
My gnome-shell also crashed with just a single display. However, my issue is not related to Eclipse either.
Similar problem has been detected: I ran KNIME, a data science tool based on Eclipse reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=c14ca7ed11664be3bb63117c7eecdf4a;i=a0277;b=3c38e5e669ad4ac588f2b1ed47e5e673;m=28fac000c;t=586be2e3f5e48;x=2f459c33403d1bb3 kernel: 5.0.7-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Print .odg through Libre Office, as soon as I clicked save the whole desktop fell apart and restarted to login screen reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=464bd60d37fa42efae9e9145da1f42d0;i=1a3e002;b=4b57c306a8a249af91a57c56462ac954;m=51afcd11b;t=5875e656ceb47;x=aad1787b7cefc4f7 kernel: 5.0.7-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1001
*** Bug 1705991 has been marked as a duplicate of this bug. ***
*** Bug 1706241 has been marked as a duplicate of this bug. ***
*** Bug 1710952 has been marked as a duplicate of this bug. ***
Similar problem has been detected: I was opening a PDF in Okular. reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=5aa5db9b8a9b4a3c845d15c8bdc3fac3;i=9e620;b=06cd64a04af74703bb1427afc0f4cc7e;m=2650a3439;t=589d1764be40f;x=2f7b77acd111d6c2 kernel: 5.0.16-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: I was updating a contact in Gnome Evolution reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=652d77a217584d21894bf76f4fa527d7;i=217;b=90f764fea11d43469fa7ac1d5d7cbe2d;m=28fbb61ad;t=58a7fb8813592;x=d0b22c40b9f7a1cb kernel: 5.0.17-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1003
*** Bug 1719293 has been marked as a duplicate of this bug. ***
*** Bug 1726324 has been marked as a duplicate of this bug. ***
*** Bug 1732567 has been marked as a duplicate of this bug. ***
Similar problem has been detected: The problem occured suddenly. I was using an application and opening a file through the "open" dialog. After clicking OK, this crash happened. reporter: libreport-2.10.1 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=97640622dbbd40099d281fe8196a8619;i=ed8d8f;b=4eead5b6d1844118b84bfa7c45814d34;m=22e709021da;t=58ece81578b29;x=d1f17099f8de968d kernel: 5.1.11-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1026
Similar problem has been detected: I loaded an stl file from Blender into Ultima Cura. reporter: libreport-2.10.1 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: shell_app_dispose executable: /usr/bin/gnome-shell journald_cursor: s=60ba5f00f8034b99a3243bfa50276d26;i=280b;b=b8f1726d6e9344d4bd8bf5418aa12bff;m=28174fb54;t=58eeaa129277a;x=8319f572d140bb7a kernel: 5.1.18-200.fc29.x86_64 package: gnome-shell-3.30.2-1.fc29 reason: gnome-shell killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 1000
*** Bug 1744186 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.