Bug 1469813 - [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by signal 5
Summary: [abrt] gnome-shell: _g_log_abort(): gnome-shell killed by signal 5
Keywords:
Status: CLOSED DUPLICATE of bug 1370073
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 27
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:3b60dd77e9b7833003d823b110a...
: 1531284 1532947 1546569 1573157 1579845 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-11 21:48 UTC by Adam Williamson
Modified: 2018-05-18 13:11 UTC (History)
39 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-16 03:37:43 UTC
Type: ---

Attachments (Terms of Use)
File: backtrace (50.01 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: cgroup (289 bytes, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: core_backtrace (28.88 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: cpuinfo (856 bytes, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: dso_list (25.18 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: environ (1.48 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: limits (1.29 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: maps (105.63 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: open_fds (6.60 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: proc_pid_status (1.26 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
File: var_log_messages (3.98 KB, text/plain)
2017-07-11 21:48 UTC, Adam Williamson 		no flags Details
system log (106.84 KB, text/x-vhdl)
2017-11-01 17:59 UTC, Mikhail 		no flags Details
View All

Description Adam Williamson 2017-07-11 21:48:29 UTC 
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
Comment 1 Adam Williamson 2017-07-11 21:48:32 UTC 
Created attachment 1296513 [details]
File: backtrace
Comment 2 Adam Williamson 2017-07-11 21:48:33 UTC 
Created attachment 1296514 [details]
File: cgroup
Comment 3 Adam Williamson 2017-07-11 21:48:34 UTC 
Created attachment 1296515 [details]
File: core_backtrace
Comment 4 Adam Williamson 2017-07-11 21:48:35 UTC 
Created attachment 1296516 [details]
File: cpuinfo
Comment 5 Adam Williamson 2017-07-11 21:48:36 UTC 
Created attachment 1296517 [details]
File: dso_list
Comment 6 Adam Williamson 2017-07-11 21:48:36 UTC 
Created attachment 1296518 [details]
File: environ
Comment 7 Adam Williamson 2017-07-11 21:48:37 UTC 
Created attachment 1296519 [details]
File: limits
Comment 8 Adam Williamson 2017-07-11 21:48:38 UTC 
Created attachment 1296520 [details]
File: maps
Comment 9 Adam Williamson 2017-07-11 21:48:40 UTC 
Created attachment 1296521 [details]
File: open_fds
Comment 10 Adam Williamson 2017-07-11 21:48:41 UTC 
Created attachment 1296522 [details]
File: proc_pid_status
Comment 11 Adam Williamson 2017-07-11 21:48:42 UTC 
Created attachment 1296523 [details]
File: var_log_messages
Comment 12 Jan Kurik 2017-08-15 06:19:43 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
Comment 13 Paweł 2017-09-28 19:57:06 UTC 
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
Comment 14 Nick Price 2017-10-03 19:50:22 UTC 
*** Bug 1498261 has been marked as a duplicate of this bug. ***
Comment 15 Jean-Pierre Rupp 2017-10-12 13:46:13 UTC 
*** Bug 1501396 has been marked as a duplicate of this bug. ***
Comment 16 Keefer Rourke 2017-10-14 19:35:14 UTC 
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
Comment 17 Henrik Nymann Jensen 2017-10-14 22:52:20 UTC 
*** Bug 1502183 has been marked as a duplicate of this bug. ***
Comment 18 Ed Marshall 2017-10-16 09:19:55 UTC 
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
Comment 19 Dawid Zamirski 2017-10-18 22:04:44 UTC 
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
Comment 20 Pavel Roskin 2017-10-18 23:59:46 UTC 
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
Comment 21 Kamil Páral 2017-10-23 08:27:23 UTC 
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
Comment 22 Dave Allan 2017-10-24 03:19:06 UTC 
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
Comment 23 Leonid Podolny 2017-10-25 13:44:23 UTC 
*** Bug 1506257 has been marked as a duplicate of this bug. ***
Comment 24 Andy Wang 2017-10-25 17:37:20 UTC 
*** Bug 1506325 has been marked as a duplicate of this bug. ***
Comment 25 Jaša Bartelj 2017-10-27 08:54:16 UTC 
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
Comment 26 Christian Stadelmann 2017-10-27 17:13:02 UTC 
*** Bug 1507099 has been marked as a duplicate of this bug. ***
Comment 27 Daniel 2017-10-30 13:26:45 UTC 
*** Bug 1507514 has been marked as a duplicate of this bug. ***
Comment 28 Mikhail 2017-11-01 03:33:22 UTC 
(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)
Comment 29 Tim Sinthofen 2017-11-01 11:43:57 UTC 
*** Bug 1508398 has been marked as a duplicate of this bug. ***
Comment 30 Mikhail 2017-11-01 17:56:28 UTC 
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
Comment 31 Mikhail 2017-11-01 17:59:44 UTC 
Created attachment 1346653 [details]
system log
Comment 32 Tim Sinthofen 2017-11-01 18:06:57 UTC 
I agree. It's an awful bug. Considering to ditch GNOME. Already lost combined (all crashes) min. 2 hours or more of work.
Comment 33 Fedora Blocker Bugs Application 2017-11-01 19:53:12 UTC 
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
Comment 34 Christian Stadelmann 2017-11-01 19:55:59 UTC 
(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
Comment 35 Adam Williamson 2017-11-01 21:16:15 UTC 
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?
Comment 36 Tim Sinthofen 2017-11-01 21:34:47 UTC 
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?
Comment 37 Adam Williamson 2017-11-01 21:46:17 UTC 
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!
Comment 38 Christian Stadelmann 2017-11-01 23:32:22 UTC 
(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.
Comment 39 Petr Schindler 2017-11-02 09:56:01 UTC 
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
Comment 40 Debarshi Ray 2017-11-02 17:08:32 UTC 
(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 ?
Comment 41 Debarshi Ray 2017-11-02 17:15:55 UTC 
(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?
Comment 42 Kamil Páral 2017-11-02 17:44:11 UTC 
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/
Comment 43 kwkaess 2017-11-02 22:34:20 UTC 
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.
Comment 44 Adam Williamson 2017-11-02 23:18:18 UTC 
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?
Comment 45 Adam Williamson 2017-11-02 23:29:33 UTC 
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.
Comment 46 Matthew Miller 2017-11-02 23:51:57 UTC 
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.
Comment 47 Adam Williamson 2017-11-02 23:55:10 UTC 
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.
Comment 48 kwkaess 2017-11-03 19:28:17 UTC 
(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.
Comment 49 Matthew Miller 2017-11-03 20:01:39 UTC 
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).
Comment 50 Adam Williamson 2017-11-03 20:38:40 UTC 
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.
Comment 51 Viktor 2017-11-08 09:56:07 UTC 
*** Bug 1510815 has been marked as a duplicate of this bug. ***
Comment 52 Bryan Hundven 2017-11-08 21:55:28 UTC 
*** Bug 1511198 has been marked as a duplicate of this bug. ***
Comment 53 b1ng0 2017-11-19 21:15:24 UTC 
*** Bug 1514983 has been marked as a duplicate of this bug. ***
Comment 54 David Vásquez 2017-11-21 17:18:57 UTC 
Temporally the people can use Kde, Xfce... Because the people use your machines for production... Is a option. KDE is working without problem.
Comment 55 kmathews 2017-11-30 10:35:22 UTC 
*** Bug 1519166 has been marked as a duplicate of this bug. ***
Comment 56 Adam Williamson 2017-12-16 03:37:43 UTC 
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 ***
Comment 57 thilina 2018-01-04 21:48:30 UTC 
*** Bug 1531284 has been marked as a duplicate of this bug. ***
Comment 58 CreativeWay 2018-01-10 04:05:59 UTC 
*** Bug 1532947 has been marked as a duplicate of this bug. ***
Comment 59 ejkustoms 2018-02-18 20:30:11 UTC 
*** Bug 1546569 has been marked as a duplicate of this bug. ***
Comment 60 shilpee 2018-04-30 11:25:17 UTC 
*** Bug 1573157 has been marked as a duplicate of this bug. ***
Comment 61 nelo.onyiah 2018-05-18 13:11:10 UTC 
*** Bug 1579845 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.