Description of problem: This crash occurred during an openQA upgrade test: https://openqa.fedoraproject.org/tests/119506 . It's a test that starts from an encrypted Fedora 25 Workstation install, and upgrades to the day's Rawhide compose (Fedora-Rawhide-20170710.n.0 , in this case). gnome-shell crashed when the test logged into the newly-upgraded system for the first time, dumping it back at the GDM screen. This doesn't seem to be a reliably reproducible crash (the same test passed yesterday), more of a quasi-random one. Version-Release number of selected component: gnome-shell-3.25.3-1.fc27 Additional info: reporter: libreport-2.9.1 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=69f01cb71e364c5883a4f92631526e0c;i=49b7;b=0af5d57771404cdba452f62b5ffc6508;m=4c9b247;t=553ff9f1ef8d5;x=7599fea8fed03dac kernel: 4.13.0-0.rc0.git3.1.fc27.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (6 frames) #0 _g_log_abort at gmessages.c:549 #1 g_log_default_handler at gmessages.c:3039 #2 default_log_handler at main.c:303 #5 wrapped_gobj_toggle_notify at gi/object.cpp:1037 #6 g_settings_backend_invoke_closure at gsettingsbackend.c:271 #12 meta_run at core/main.c:648 Potential duplicate: bug 1397668
Created attachment 1296513 [details] File: backtrace
Created attachment 1296514 [details] File: cgroup
Created attachment 1296515 [details] File: core_backtrace
Created attachment 1296516 [details] File: cpuinfo
Created attachment 1296517 [details] File: dso_list
Created attachment 1296518 [details] File: environ
Created attachment 1296519 [details] File: limits
Created attachment 1296520 [details] File: maps
Created attachment 1296521 [details] File: open_fds
Created attachment 1296522 [details] File: proc_pid_status
Created attachment 1296523 [details] File: var_log_messages
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Similar problem has been detected: Installed Fedora 27 pre-beta, updated an this happened. reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=31740719cdfc44e293331183fa7d2b5d;i=2697;b=f24c7aee7fcc418092d13136ebf452c2;m=373f1c8c;t=55a45324db3a0;x=6972cc88ed3b2c27 kernel: 4.13.3-301.fc27.x86_64 package: gnome-shell-3.26.0-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
*** Bug 1498261 has been marked as a duplicate of this bug. ***
*** Bug 1501396 has been marked as a duplicate of this bug. ***
Similar problem has been detected: GNOME Shell 3.26.1 crashes every time I plug in my external monitor via HDMI to my laptop running Fedora 27 beta. This machine runs a 7th generation Intel i5-7200U processor with Intel HD 620 Kaby Lake graphics. reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=c2046ae79f9444de8cc27accbbd53f50;i=1699b;b=d4bdda4bc3b944808bfea68e7179a97c;m=2584014a8;t=55b86b8a39f20;x=b68f10fec34bcc60 kernel: 4.13.5-300.fc27.x86_64 package: gnome-shell-3.26.1-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
*** Bug 1502183 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Unlocked the screen, and was bounced to GDM. reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=0c32b52a012d4dd88df3ca02188c9c2d;i=1df44;b=3f35ac64c827457e9fac68bdbef8f67e;m=1a39cc596e;t=55ba667b5eb01;x=1171a6eaf1db10d1 kernel: 4.13.6-300.fc27.x86_64 package: gnome-shell-3.26.1-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Close VBOX GUI window. reporter: libreport-2.9.2 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=90f7bb5473b147c0bf7998bbbf500f79;i=347f9;b=35cf3b4d9d0e44b1b5e1c63f866acc3d;m=19e9c7d2e4;t=55bd95c9801c3;x=c9dd73efeb301c6e kernel: 4.13.6-300.fc27.x86_64 package: gnome-shell-3.26.1-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: The crash is still happening, but under more specific conditions. 1) Open gedit 2) Type something in the gedit window 3) Press and release the Windows key 4) Close the gedit window using the mouse gedit shows the save dialog, GNOME Shell crashes. My system is up to date with updates-testing, including mutter-3.26.1-3.fc27.x86_64 reporter: libreport-2.9.2 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=a51ed95ed6a74bce84bcef10a514eb97;i=1b7e;b=cb836ae599804bf1947f10d94799e22d;m=454465f68;t=55bdac32729d3;x=d755254acfcc29ea kernel: 4.13.6-300.fc27.x86_64 package: gnome-shell-3.26.1-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Logging it took several minutes. It seems gnome-shell tried to start so many times that it exhausted the limit for opened files. After few minutes, the login succeeded. reporter: libreport-2.9.2 backtrace_rating: 3 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=fc341d846b21453a81cb285ead9a4bdd;i=2ed43;b=d5da0b1bf8e54e25a8979c4353422665;m=7860c26;t=55c328340f302;x=87cf04b07df636ca kernel: 4.13.8-300.fc27.x86_64 package: gnome-shell-3.26.1-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Happened immediately after logout and relogin reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=09f78bcc68f043d29cf4e62ea1fdba02;i=4056;b=b6292284b56e4ce2b321c347c582a8bf;m=1768c106b;t=55c424b698294;x=16f56ef5382977a6 kernel: 4.13.8-300.fc27.x86_64 package: gnome-shell-3.26.1-2.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
*** Bug 1506257 has been marked as a duplicate of this bug. ***
*** Bug 1506325 has been marked as a duplicate of this bug. ***
Similar problem has been detected: logging in to a new session reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=84a73eb834bf482f88f7a4977cb276bd;i=240a;b=21c1a17f74ee4be5ab7770abb77f47e3;m=1dd391b9;t=55c82cd26a491;x=c827bacc2b5ac4e2 kernel: 4.13.9-300.fc27.x86_64 package: gnome-shell-3.26.1-2.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
*** Bug 1507099 has been marked as a duplicate of this bug. ***
*** Bug 1507514 has been marked as a duplicate of this bug. ***
(gdb) thread apply all bt Thread 17 (Thread 0x7f080c35d700 (LWP 1974)): #0 0x00007f081ed5c8bb in __GI___poll (fds=0x5559010652a0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f0820ddaed9 in g_main_context_poll (priority=<optimized out>, n_fds=2, fds=0x5559010652a0, timeout=<optimized out>, context=0x555901064100) at gmain.c:4187 #2 0x00007f0820ddaed9 in g_main_context_iterate (context=context@entry=0x555901064100, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 #3 0x00007f0820ddafec in g_main_context_iteration (context=0x555901064100, may_block=may_block@entry=1) at gmain.c:3947 #4 0x00007f0820ddb031 in glib_worker_main (data=<optimized out>) at gmain.c:5742 #5 0x00007f0820e024c6 in g_thread_proxy (data=0x555901064400) at gthread.c:784 #6 0x00007f081f03b609 in start_thread (arg=0x7f080c35d700) at pthread_create.c:465 #7 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 16 (Thread 0x7f07d47f8700 (LWP 2053)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163d7e8) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x55590145ab90) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x55590145ab90) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d47f8700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 15 (Thread 0x7f07d4ff9700 (LWP 2052)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b08) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163d310) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x55590145ab70) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x55590145ab70) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d4ff9700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 14 (Thread 0x7f07d57fa700 (LWP 2051)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., wh---Type <return> to continue, or q <return> to quit--- ich=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163ce38) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x555901471d40) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x555901471d40) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d57fa700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 13 (Thread 0x7f07d5ffb700 (LWP 2050)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163c960) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x555901471d20) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x555901471d20) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d5ffb700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 12 (Thread 0x7f07d67fc700 (LWP 2049)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b08) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163c488) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x555901471d00) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x555901471d00) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d67fc700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 11 (Thread 0x7f07d6ffd700 (LWP 2048)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163bfb0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x55590146a3e0) ---Type <return> to continue, or q <return> to quit--- at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x55590146a3e0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d6ffd700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 10 (Thread 0x7f07d77fe700 (LWP 2047)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163bad8) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x55590146a3c0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x55590146a3c0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d77fe700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 9 (Thread 0x7f07d7fff700 (LWP 2046)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163b600) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x55590146a3a0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x55590146a3a0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07d7fff700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 8 (Thread 0x7f07e93ca700 (LWP 2044)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b08) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163ac50) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x5559014b04a0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x5559014b04a0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07e93ca700) at pthread_create.c:465 ---Type <return> to continue, or q <return> to quit--- #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 7 (Thread 0x7f07e9bcb700 (LWP 2043)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163a778) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x5559014b0480) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x5559014b0480) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07e9bcb700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 6 (Thread 0x7f07ea3cc700 (LWP 2042)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163a2a0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x5559014eec10) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x5559014eec10) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07ea3cc700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7f07eabcd700 (LWP 2041)): #0 0x00007f081ed5c8bb in __GI___poll (fds=fds@entry=0x7f07e4007120, nfds=nfds@entry=3, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f07fc0c26f1 in poll (__timeout=-1, __nfds=3, __fds=0x7f07e4007120) at /usr/include/bits/poll2.h:46 #2 0x00007f07fc0c26f1 in poll_func (ufds=0x7f07e4007120, nfds=3, timeout=-1, userdata=0x555901512bb0) at pulse/thread-mainloop.c:69 #3 0x00007f07fc0b40b0 in pa_mainloop_poll (m=m@entry=0x555901498f00) at pulse/mainloop.c:844 #4 0x00007f07fc0b4740 in pa_mainloop_iterate (m=0x555901498f00, block=<optimized out>, retval=0x0) at pulse/mainloop.c:926 #5 0x00007f07fc0b47d0 in pa_mainloop_run (m=0x555901498f00, retval=retval@entry=0x0) at pulse/mainloop.c:944 #6 0x00007f07fc0c2639 in thread (userdata=0x5559013e9f80) at pulse/thread-mainloop.c:100 #7 0x00007f07efdd2ac8 in internal_thread_func (userdata=0x555901530f30) at pulsecore/thread-posix.c:81 #8 0x00007f081f03b609 in start_thread (arg=0x7f07eabcd700) at pthread_create.c:465 #9 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7f080a94d700 (LWP 1980)): #0 0x00007f081ed5c8bb in __GI___poll (fds=0x55590108f030, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f0820ddaed9 in g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x55590108f030, timeout=<optimized out>, context=0x55590108f0c0) at gmain.c:4187 #2 0x00007f0820ddaed9 in g_main_context_iterate (context=context@entry=0x55590108f0c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 #3 0x00007f0820ddafec in g_main_context_iteration (context=context@entry=0x55590108f0c0, may_block=may_block@entry=1) at gmain.c:3947 ---Type <return> to continue, or q <return> to quit--- #4 0x00007f080a95542d in dconf_gdbus_worker_thread (user_data=0x55590108f0c0) at dconf-gdbus-thread.c:82 #5 0x00007f0820e024c6 in g_thread_proxy (data=0x555901064e80) at gthread.c:784 #6 0x00007f081f03b609 in start_thread (arg=0x7f080a94d700) at pthread_create.c:465 #7 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f080bb5c700 (LWP 1975)): #0 0x00007f081ed5c8bb in __GI___poll (fds=0x7f0778011ed0, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f0820ddaed9 in g_main_context_poll (priority=<optimized out>, n_fds=4, fds=0x7f0778011ed0, timeout=<optimized out>, context=0x555901082d60) at gmain.c:4187 #2 0x00007f0820ddaed9 in g_main_context_iterate (context=0x555901082d60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 #3 0x00007f0820ddb272 in g_main_loop_run (loop=0x555901082ea0) at gmain.c:4082 #4 0x00007f08213c3b36 in gdbus_shared_thread_func (user_data=0x555901082d30) at gdbusprivate.c:275 #5 0x00007f0820e024c6 in g_thread_proxy (data=0x5559010644a0) at gthread.c:784 #6 0x00007f081f03b609 in start_thread (arg=0x7f080bb5c700) at pthread_create.c:465 #7 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f07e8bc9700 (LWP 2045)): #0 0x00007f081f041c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555901061b0c) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x00007f081f041c3b in __pthread_cond_wait_common (abstime=0x0, mutex=0x555901059be0, cond=0x555901061ae0) at pthread_cond_wait.c:502 #2 0x00007f081f041c3b in __pthread_cond_wait (cond=0x555901061ae0, mutex=0x555901059be0) at pthread_cond_wait.c:655 #3 0x00007f08172a69c4 in js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (this=<optimized out>, lock=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:118 #4 0x00007f08172a6c35 in js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x555901061ae0, lock=..., a_rel_time=...) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/posix/ConditionVariable.cpp:134 #5 0x00007f081769f1e3 in js::GlobalHelperThreadState::wait(js::AutoLockHelperThreadState&, js::GlobalHelperThreadState::CondVar, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>) (timeout=..., which=js::GlobalHelperThreadState::PRODUCER, locked=..., this=<optimized out>) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:786 #6 0x00007f081769f1e3 in js::HelperThread::threadLoop() (this=0x55590163b128) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/vm/HelperThreads.cpp:1868 #7 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul>(mozilla::IndexSequence<0ul>) (this=0x5559014b04c0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:234 #8 0x00007f08176c0802 in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (aPack=0x5559014b04c0) at /usr/src/debug/mozjs52-52.4.0-1.fc27.x86_64/threading/Thread.h:227 #9 0x00007f081f03b609 in start_thread (arg=0x7f07e8bc9700) at pthread_create.c:465 #10 0x00007f081ed68e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f0821ca4f80 (LWP 1972)): #0 0x00007f0820de07b1 in _g_log_abort (breakpoint=1) at gmessages.c:554 #1 0x00007f0820de17ec in g_log_default_handler (log_domain=<optimized out>, log_level=<optimized out>, message=<optimized out>, unused_data=<optimized out>) at gmessages.c:3051 #2 0x00005558ff194735 in default_log_handler (log_domain=log_domain@entry=0x7f081f36a893 "mutter", log_level=log_level@entry=6, message=message@entry=0x55590427fc50 "Connection to xwayland lost", data=data@entry=0x0) at ../src/main.c:311 #3 0x00007f0820de1a7d in g_logv (log_domain=0x7f081f36a893 "mutter", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry=0x7ffe572fda70) at gmessages.c:1341 #4 0x00007f0820de1bef in g_log (log_domain=log_domain@entry=0x7f081f36a893 "mutter", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7f081f37cd30 "Connection to xwayland lost") at gmessages.c:1403 #5 0x00007f081f32ba8e in x_io_error (display=<optimized out>) at wayland/meta-xwayland.c:411 #6 0x00007f081da14ede in _XIOError (dpy=dpy@entry=0x555901396820) at XlibInt.c:1469 #7 0x00007f081da1276d in _XEventsQueued (dpy=dpy@entry=0x555901396820, mode=mode@entry=2) at xcb_io.c:352 #8 0x00007f081da042bd in XPending (dpy=0x555901396820) at Pending.c:55 #9 0x00007f081e565851 in gdk_event_source_check () at /lib64/libgdk-3.so.0 #10 0x00007f0820dda909 in g_main_context_check (context=context@entry=0x5559010652c0, max_priority=2147483647, fds=fds@entry=0x5559064ab170, n_fds=n_fds@entry=18) at gmain.c:3719 #11 0x00007f0820ddae80 in g_main_context_iterate (context=0x5559010652c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3883 #12 0x00007f0820ddb272 in g_main_loop_run (loop=0x5559013745b0) at gmain.c:4082 #13 0x00007f081f2f72cc in meta_run () at core/main.c:648 #14 0x00005558ff194267 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:462 (gdb) (gdb) (gdb)
*** Bug 1508398 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Most annoying today gnome-shell issue because every time gnome-shell crashed all application are terminated and losing all data. And it happens always unexpectedly. reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=080dd602856d412c9a43640ef29bfca7;i=25b839;b=031d7f25a05846ab8c05d80d9a8b5f93;m=1e492f328;t=55cef76a60a90;x=96a6129b283560be kernel: 4.13.10-300.fc27.x86_64+debug package: gnome-shell-3.26.1-2.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1346653 [details] system log
I agree. It's an awful bug. Considering to ditch GNOME. Already lost combined (all crashes) min. 2 hours or more of work.
Proposed as a Blocker and Freeze Exception for 27-final by Fedora user genodeftest using the blocker tracking app because: This is a common bug (see all the comments, CC list members and duplicates) and often causes data loss. Probably violated criteria: * "All known bugs that can cause corruption of user data must be fixed or documented at Common F27 bugs." – User data is lost, so this criterion is violated – https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Data_corruption * "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." – gnome-shell is the "default panel" equivalent and keeps crashing – https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Default_panel_functionality
(In reply to Fedora Blocker Bugs Application from comment #33) > Proposed as a Blocker and Freeze Exception for 27-final by Fedora user > genodeftest using the blocker tracking app because: In case this bug does not become a blocker, please make it a prioritized bug. I cant't do that, but the process is described here: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process
It would really help to have some kind of idea of what triggers the remaining crash(es?) For instance, I've been running GNOME on F27 throughout its entire cycle and I've never once hit this crash. So there must be *some* relationship to how you use GNOME, or hardware, or installed extensions, or *something*. There's one suggested reproducer in #c20, and some people seem to be suggesting it's happening on session login (though that may just be a misunderstanding caused by them seeing the *notification* after their session crashed and they started a new one). Mikhail, Tim, can you recall what you were doing when the crash happened?
I can not reproduce C20. I was working with LibreOffice Impress, it froze, GNOME shell crashed to login screen. Was not able to Login (after typing in password, it tried to load the shell but jumped back to login). Had to reboot to be able to login again. Once in Fedora 26 something similar happened (but there I activated an extension) and I had to wipe the settings in my home-folder to be able to login again. I guess I cant help, as I don't know how to reproduce it. I hoped the logs would help. It seems they are useless?
No no, more information is always more useful, I'm just trying to gather as much as possible. So you didn't have any extensions enabled when you ran into this, and you were working in LibreOffice Impress? Do you recall exactly what action you took right when it crashed? Thanks!
(In reply to Tim Sinthofen from comment #36) > I was working with LibreOffice Impress, it froze, GNOME shell crashed to > login screen. Was not able to Login (after typing in password, it tried to > load the shell but jumped back to login). Had to reboot to be able to login > again. I'm seeing the same double-crash scenario too (see my duplicate of this bug report, bug #1507099). First gnome-shell crashes back to gdm, then any following login attempts fail. I could only login again after reboot or after killing some of the remaining processes running under my user ID. I'm not sure whether the first or the second crash is triggering this backtrace here, so this backtrace might just be the result of an unrelated bug – I don't know. I cannot reproduce comment #20 either.
Similar problem has been detected: Gnome-shell crashed when I tried to switch users. Crashed happened right after I clicked on switch user. This system was installed from Workstation Live RC 1.2 reporter: libreport-2.9.2 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: _g_log_abort executable: /usr/bin/gnome-shell journald_cursor: s=e02dce70e5914326a6e9c2da96659bff;i=16a7;b=60c6935cb65844089c4cfda28d731b0d;m=66498ec0;t=55cfcdabba04c;x=540c73094a9ef1a5 kernel: 4.13.9-300.fc27.x86_64 package: gnome-shell-3.26.1-1.fc27 reason: gnome-shell killed by SIGTRAP rootdir: / runlevel: N 5 type: CCpp uid: 1001
(In reply to Adam Williamson from comment #35) > some people seem > to be suggesting it's happening on session login Could be https://bugzilla.gnome.org/show_bug.cgi?id=787422 ?
(In reply to Mikhail from comment #28) > (gdb) thread apply all bt > > [...] > > Thread 1 (Thread 0x7f0821ca4f80 (LWP 1972)): > #0 0x00007f0820de07b1 in _g_log_abort (breakpoint=1) at gmessages.c:554 > #1 0x00007f0820de17ec in g_log_default_handler (log_domain=<optimized out>, > log_level=<optimized out>, message=<optimized out>, unused_data=<optimized > out>) at gmessages.c:3051 > #2 0x00005558ff194735 in default_log_handler > (log_domain=log_domain@entry=0x7f081f36a893 "mutter", > log_level=log_level@entry=6, message=message@entry=0x55590427fc50 > "Connection to xwayland lost", data=data@entry=0x0) at ../src/main.c:311 > #3 0x00007f0820de1a7d in g_logv (log_domain=0x7f081f36a893 "mutter", > log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, > args=args@entry=0x7ffe572fda70) at gmessages.c:1341 > #4 0x00007f0820de1bef in g_log (log_domain=log_domain@entry=0x7f081f36a893 > "mutter", log_level=log_level@entry=G_LOG_LEVEL_ERROR, > format=format@entry=0x7f081f37cd30 "Connection to xwayland lost") > at gmessages.c:1403 > #5 0x00007f081f32ba8e in x_io_error (display=<optimized out>) at > wayland/meta-xwayland.c:411 > #6 0x00007f081da14ede in _XIOError (dpy=dpy@entry=0x555901396820) at > XlibInt.c:1469 > #7 0x00007f081da1276d in _XEventsQueued (dpy=dpy@entry=0x555901396820, > mode=mode@entry=2) at xcb_io.c:352 > #8 0x00007f081da042bd in XPending (dpy=0x555901396820) at Pending.c:55 > #9 0x00007f081e565851 in gdk_event_source_check () at /lib64/libgdk-3.so.0 > #10 0x00007f0820dda909 in g_main_context_check > (context=context@entry=0x5559010652c0, max_priority=2147483647, > fds=fds@entry=0x5559064ab170, n_fds=n_fds@entry=18) at gmain.c:3719 > #11 0x00007f0820ddae80 in g_main_context_iterate (context=0x5559010652c0, > block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at > gmain.c:3883 > #12 0x00007f0820ddb272 in g_main_loop_run (loop=0x5559013745b0) at > gmain.c:4082 > #13 0x00007f081f2f72cc in meta_run () at core/main.c:648 > #14 0x00005558ff194267 in main (argc=<optimized out>, argv=<optimized out>) > at ../src/main.c:462 Was there an XWayland crash corresponding to this?
Discussed during blocker review [1]: punt (delay decision) - this is a rather complex report with probably multiple different problems bundled up together, we don't yet really have the information to make a determination [1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-02/
This may not be helpful, but... After some recent package upgrades, including mesa-17.2.4, this type of crash (for which there are numerous causes it seems) no longer boots me out to the login screen. It still crashes gnome-shell, though.
So if you're running GNOME on X, Shell crashes aren't usually fatal; when Shell crashes it gets automatically restarted and your session continues. If you're running GNOME on Wayland, Shell crashes usually *are* fatal, because effectively the Shell *is* the display manager, when it crashes, the whole session dies. Possibly you used to wind up with GNOME on Wayland but now you wind up with GNOME on X? Otherwise I'm not sure. What *does* happen when you hit your crash?
So I've looked more carefully into all the reports and dupes here, and indeed I'm fairly sure that we don't really have one bug that a lot of people are running into. We have lots of different bugs which abrt/libreport are wrongly considering duplicates of this bug, I think because they all run through the same last few steps of a codepath in glib (default_log_handler -> g_log_default_handler -> _g_log_abort . This is explained in the g_log_default_handler description: " * g_log_default_handler: * @log_domain: (nullable): the log domain of the message, or %NULL for the * default "" application domain * @log_level: the level of the message * @message: (nullable): the message * @unused_data: (nullable): data passed from g_log() which is unused * * The default log handler set up by GLib; g_log_set_default_handler() * allows to install an alternate default log handler. * This is used if no log handler has been set for the particular log * domain and log level combination. It outputs the message to stderr * or stdout and if the log level is fatal it calls abort(). " default_log_handler is in gnome-shell's main.c , it's just a fairly light wrapper around glib g_log_default_handler . So I think we wind up down this codepath basically any time something goes wrong and causes some kind of 'fatal' error to be logged through the shell. I've filed a bug on libreport about this: https://bugzilla.redhat.com/show_bug.cgi?id=1509086 I've also re-opened all the dupes with a bit of analysis and a request for more info. For all reporters, if you have a crash that abrt told you was a duplicate of this one and it did *not* file a duplicate bug that I re-opened, can you please file a bug manually, including all the information on your crash that you can? At least we need the system logs, a description of what you were doing at the time, and info on any enabled extensions. If possible a backtrace of the crash (and any underlying crashes) would be super useful. Thanks.
That makes sense to me. I think the best thing we can do here is work with the GNOME and RH desktop teams to emphasize the importance of figuring out a way to separate the shell from the wayland compsitor, to reduce the impact of shell crashes. I know that's a tall order since it's pretty deep in the design, so I don't expect an immediate fix but hopefully we can go in that direction, because it's a much better user experience. (I mean, ideally, nothing would crash ever, but, failing that....) Anyway, because of all that, -1 to blocker for F27.
That would be a significant improvement, yes. I am also clearly -1 blocker on *this* bug, as the original filer; the actual original bug I filed here happened quite infrequently in automated testing, I'm not sure it ever happens any more. However, we could still consider the cases of all the dupes. The one that would worry/interest me the most is #1506325 / #1502183 / #1508398 , which I *think* are all the same and seem to involve an erroneous attempt to allocate a huge amount of memory for some reason.
(In reply to Adam Williamson from comment #44) > So if you're running GNOME on X, Shell crashes aren't usually fatal; when > Shell crashes it gets automatically restarted and your session continues. > > If you're running GNOME on Wayland, Shell crashes usually *are* fatal, > because effectively the Shell *is* the display manager, when it crashes, the > whole session dies. > > Possibly you used to wind up with GNOME on Wayland but now you wind up with > GNOME on X? Otherwise I'm not sure. What *does* happen when you hit your > crash? Hah, that was exactly it. I just forgot that I had switched over to see if things got better. That said, another probably misleading possibility - I updated my kernel to 4.13.11, and haven't had a crash in 1.5 days.
For "shell crashes on Wayland are fatal" please see bug #1367666 (but no need to comment or add extra noise there -- that's not generally helpful since we're already aware that the issue is significant).
Discussed at 2017-11-01 to 2017-11-02 Fedora 27 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-02/f27-final-and-server-beta-go-no-go-meeting.2017-11-02-17.00.html . We ultimately decided against accepting this as a blocker bug or freeze exception bug, given all the above research. The actual crash initially reported here is clearly not encountered commonly enough to block the release. The number of duplicates certainly indicates that there are various crasher bugs in GNOME Shell in F27, and that sucks. But then, there were certainly crasher bugs in GNOME Shell in all previous releases, too. We generally only block the release on bugs that seem to be affecting a large number of users very badly. On review, none of these bugs seems to meet that standard, and we don't have any information suggesting Shell in F27 is any *more* crashy than any other release we've cut since the Wayland switch. So we don't see any value in blocking F27 on any one of these crasher bugs either. What we'd really like to see going forward is some kind of fix for #1367666, so Shell crashes on Wayland don't bring the session down any more. It seems too much to hope for some kind of magic wand we can wave to prevent Shell ever crashing for anyone.
*** Bug 1510815 has been marked as a duplicate of this bug. ***
*** Bug 1511198 has been marked as a duplicate of this bug. ***
*** Bug 1514983 has been marked as a duplicate of this bug. ***
Temporally the people can use Kde, Xfce... Because the people use your machines for production... Is a option. KDE is working without problem.
*** Bug 1519166 has been marked as a duplicate of this bug. ***
For my original report here, the actual error was: "toggling down object GSettings that's already queued to toggle up" which is the same error as the initial report in #1370073 (which is *another* bug that's subject to this 'false dupe' problem). So I'm gonna close this as a dupe of that. *** This bug has been marked as a duplicate of bug 1370073 ***
*** Bug 1531284 has been marked as a duplicate of this bug. ***
*** Bug 1532947 has been marked as a duplicate of this bug. ***
*** Bug 1546569 has been marked as a duplicate of this bug. ***
*** Bug 1573157 has been marked as a duplicate of this bug. ***
*** Bug 1579845 has been marked as a duplicate of this bug. ***