Created attachment 1348681 [details] system log Description of problem: Core was generated by `/usr/bin/Xwayland :0 -rootless -terminate -core -listen 4 -listen 5 -displayfd'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 } [Current thread is 1 (Thread 0x7ff10e6fba80 (LWP 1941))] (gdb) thread apply all bt Thread 9 (Thread 0x7ff100bb2700 (LWP 1945)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a1aa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1a58, cond=0x24a1a80) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a1a80, mutex=0x24a1a58) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff100bb2700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 8 (Thread 0x7ff101bb4700 (LWP 1942)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a1670) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1620, cond=0x24a1648) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a1648, mutex=0x24a1620) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff101bb4700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 7 (Thread 0x7ff0fbfff700 (LWP 1946)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a1c10) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1bc0, cond=0x24a1be8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a1be8, mutex=0x24a1bc0) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff0fbfff700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 6 (Thread 0x7ff1013b3700 (LWP 1943)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a17d8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1788, cond=0x24a17b0) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a17b0, mutex=0x24a1788) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff1013b3700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7ff0f8bb2700 (LWP 1944)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a1940) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a18f0, cond=0x24a1918) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a1918, mutex=0x24a18f0) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff0f8bb2700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7ff0fa7fc700 (LWP 1949)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a2048) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1ff8, cond=0x24a2020) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a2020, mutex=0x24a1ff8) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so ---Type <return> to continue, or q <return> to quit--- #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff0fa7fc700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7ff0fb7fe700 (LWP 1947)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a1d78) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1d28, cond=0x24a1d50) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a1d50, mutex=0x24a1d28) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff0fb7fe700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7ff0faffd700 (LWP 1948)): #0 0x00007ff10b790c3b in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x24a1ee0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x24a1e90, cond=0x24a1eb8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x24a1eb8, mutex=0x24a1e90) at pthread_cond_wait.c:655 #3 0x00007ff10589797b in thread_function () from /usr/lib64/dri/swrast_dri.so #4 0x00007ff1058977f7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #5 0x00007ff10b78a609 in start_thread (arg=0x7ff0faffd700) at pthread_create.c:465 #6 0x00007ff10b4b7e6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7ff10e6fba80 (LWP 1941)): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ff10b3d73b1 in __GI_abort () at abort.c:79 #2 0x0000000000594a9a in OsAbort () at utils.c:1361 #3 0x0000000000599c63 in AbortServer () at log.c:877 #4 0x000000000059aa85 in FatalError (f=f@entry=0x5a3700 "failed to read Wayland events: %s\n") at log.c:1015 #5 0x000000000042334d in xwl_read_events (xwl_screen=0x1c10c10) at xwayland.c:594 #6 0x0000000000592611 in ospoll_wait (ospoll=0x1c060b0, timeout=<optimized out>) at ospoll.c:412 #7 0x000000000058be1b in WaitForSomething (are_ready=<optimized out>) at WaitFor.c:226 #8 0x0000000000557c33 in Dispatch () at dispatch.c:422 #9 0x000000000055bed0 in dix_main (argc=11, argv=0x7ffe1c21aea8, envp=<optimized out>) at main.c:287 #10 0x00007ff10b3bf03a in __libc_start_main (main=0x422a00 <main>, argc=11, argv=0x7ffe1c21aea8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1c21ae98) at ../csu/libc-start.c:308 #11 0x0000000000422a3a in _start () (gdb) (gdb)
That's an abort: #3 0x0000000000599c63 in AbortServer () at log.c:877 #4 0x000000000059aa85 in FatalError (f=f@entry=0x5a3700 "failed to read Wayland events: %s\n") at log.c:1015 Most likely the Wayland compositor is gone, ie a crash in gnome-shell/mutter
Can you quickly check in the logs at the time of the crash if gnome-shell/mutter had crashed or failed to start (I've seen this happening as well at startup, gnome-shell starts, spawns Xwayland, then fails, and Xwayland aborts in xwl_read_events())
I am getting the same crash, had it happen today on login. And yes, I am seeing gnome-shell crash 1 second before Xwayland does so. The backtrace is identical with the one in https://bugzilla.redhat.com/show_bug.cgi?id=1507656.
(In reply to Christian Stadelmann from comment #3) > I am getting the same crash, had it happen today on login. And yes, I am > seeing gnome-shell crash 1 second before Xwayland does so. The backtrace is > identical with the one in > https://bugzilla.redhat.com/show_bug.cgi?id=1507656. Right, this is a mutter issue. However, the backtrace from bug 1507656 does not match the issue here so I wouldn;t close this one as a dupe of bug 1507656 because I do not think they are the same. Based on the logs (attachment 1348681 [details]), it seems this is an Xerror that caused the premature death of gnome-shell, not a segfault: gnome-shell[1921]: The program 'gnome-shell' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 273157 error_code 11 request_code 12 (core protocol) minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) This is also confirmed by the backtrace found further down the logs (attachment 1348681 [details]): Stack trace of thread 1921: #0 0x00007fd10371b90b raise (libpthread.so.0) #1 0x0000557a4290ea0b dump_gjs_stack_on_signal_handler (gnome-shell) #2 0x00007fd10371ba70 __restore_rt (libpthread.so.0) #3 0x00007fd1054b77b1 _g_log_abort (libglib-2.0.so.0) #4 0x00007fd1054b9de1 g_log_writer_default (libglib-2.0.so.0) #5 0x00007fd1054b834e g_log_structured_array (libglib-2.0.so.0) #6 0x00007fd1054b8647 g_log_structured (libglib-2.0.so.0) #7 0x00007fd102c321e1 _gdk_x11_display_error_event (libgdk-3.so.0) #8 0x00007fd102c3f783 gdk_x_error (libgdk-3.so.0) #9 0x00007fd08bdedcc2 xkl_process_error (libxklavier.so.16) #10 0x00007fd1020e8e3a _XError (libX11.so.6) #11 0x00007fd1020e5d6b handle_error (libX11.so.6) #12 0x00007fd1020e5e15 handle_response (libX11.so.6) #13 0x00007fd1020e6745 _XEventsQueued (libX11.so.6) #14 0x00007fd1020d82bd XPending (libX11.so.6) #15 0x00007fd102c39b91 gdk_check_xpending (libgdk-3.so.0) #16 0x00007fd1054b1909 g_main_context_check (libglib-2.0.so.0) #17 0x00007fd1054b1e80 g_main_context_iterate (libglib-2.0.so.0) #18 0x00007fd1054b2272 g_main_loop_run (libglib-2.0.so.0) #19 0x00007fd1039cc4fc meta_run (libmutter-1.so.0) #20 0x0000557a4290e42c main (gnome-shell) #21 0x00007fd10334503a __libc_start_main (libc.so.6) #22 0x0000557a4290e56a _start (gnome-shell) Now, X11 being asynchronous, the error being caught in libxklavier doesn't necessarily mean this is originally from libxklavier. request code 12 would be ConfigureWindow and error 11 a BadAlloc, it's pretty much all I could say with this.
Maybe that is related to my issue Bug 1513807 ?
I have not seen this issue in Fedora 28/29 for a few months. It probably has been closed.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.