Description of problem: I replugged my monitor to my system Version-Release number of selected component: xorg-x11-server-Xwayland-1.20.0-5.fc29 Additional info: reporter: libreport-2.9.5 crash_function: OsLookupColor executable: /usr/bin/Xwayland kernel: 4.18.0-0.rc4.git4.1.fc29.x86_64 runlevel: N 5 type: xorg uid: 0 Truncated backtrace: 0: /usr/bin/Xwayland (OsLookupColor+0x13d) [0x58e5ad] 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7fc05acee97f] 2: ? (?+0x0) [0x400000000]
Created attachment 1471018 [details] File: backtrace
Created attachment 1471019 [details] File: cpuinfo
Created attachment 1471020 [details] File: dmesg
Created attachment 1471021 [details] File: dso_list
Created attachment 1471022 [details] File: etc_X11_xorg_conf_d.tar.gz
Created attachment 1471023 [details] File: usr_share_xorg_conf_d.tar.gz
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Description of problem: Same as https://bugzilla.redhat.com/show_bug.cgi?id=1655998 Version-Release number of selected component: xorg-x11-server-Xwayland-1.20.3-1.fc29 Additional info: reporter: libreport-2.9.7 crash_function: OsLookupColor executable: /usr/bin/Xwayland kernel: 4.19.6-300.fc29.x86_64 runlevel: N 5 type: xorg uid: 0 Truncated backtrace: 0: /usr/bin/Xwayland (OsLookupColor+0x13d) [0x561af420c1ed] 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7f5e0d32b0bf] 2: ? (?+0x0) [0xffffffffffffffff]
*** Bug 1663997 has been marked as a duplicate of this bug. ***
Unfortunately the backtrace is pretty useless, it's impossible to draw any conclusion based on such little data. Same for the Xorg.log, there are none with Xwayland so it's useless. I would be more interested to hear about the journalctl logs for gnome-shell at the time of the crash. Something like "journalctl /usr/bin/gnome-shell"
Hope the below is more informative. If not, let me know how I can help you. Jan 07 09:57:42 localhost.localdomain org.gnome.Shell.desktop[3462]: Window manager warning: last_focus_time (4891714) is greater than comparison timestamp (4891705). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... Jan 07 09:59:33 localhost.localdomain gnome-shell[3462]: An active wireless connection, in infrastructure mode, involves no access point? Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Backtrace: Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) 0: /usr/bin/Xwayland (OsLookupColor+0x13d) [0x559e1bef526d] Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7fb01e4e807f] Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) unw_get_proc_name failed: no unwind info found [-10] Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) 2: /lib64/libc.so.6 (?+0x0) [0x7fb01e4d0470] Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Segmentation fault at address 0x7fb01e4d0470 Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: Fatal server error: Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Caught signal 11 (Segmentation fault). Server aborting Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: (EE) Jan 07 10:01:47 localhost.localdomain firefox.desktop[3462]: Gdk-Message: 10:01:47.701: /usr/lib64/firefox/firefox: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: Connection lost to X server ':0' Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: When compiled with GTK, Emacs cannot recover from X disconnects. Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715 Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: For details, see etc/PROBLEMS. Jan 07 10:01:47 localhost.localdomain firefox.desktop[3462]: Gdk-Message: 10:01:47.701: /usr/lib64/firefox/firefox: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: Backtrace: Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x51a552] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4ffade] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x51a609] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4cbec3] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4cbfdb] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libX11.so.6(_XIOError+0x52)[0x7f44ab6764a2] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libX11.so.6(+0x475ac)[0x7f44ab6745ac] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libXrandr.so.2(XRRGetMonitors+0x9b)[0x7f44a6ae4ffb] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x760cd)[0x7f44abd1c0cd] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x76f09)[0x7f44abd1cf09] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x772f1)[0x7f44abd1d2f1] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x688a4)[0x7f44abd0e8a4] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x6ecbc)[0x7f44abd14cbc] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x6e7c5)[0x7f44abd147c5] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(gdk_display_get_event+0x44)[0x7f44abcddc34] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgdk-3.so.0(+0x6e436)[0x7f44abd14436] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x15d)[0x7f44ab7f106d] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libglib-2.0.so.0(+0x4f438)[0x7f44ab7f1438] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libglib-2.0.so.0(g_main_context_iteration+0x30)[0x7f44ab7f14d0] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libgtk-3.so.0(gtk_main_iteration+0x19)[0x7f44abff2c09] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4cc8b2] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x506eb9] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x5074c5] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x5c0d55] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x50b15d] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x50d6d0] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x50eda4] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x577946] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4ffeb4] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x5778b5] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4ffe53] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x505017] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x505378] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x420b28] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f44a6347413] Jan 07 10:01:47 localhost.localdomain emacs.desktop[3462]: emacs[0x4217be] Jan 07 10:01:47 localhost.localdomain gnome-shell[3462]: Connection to xwayland lost Jan 07 10:01:47 localhost.localdomain firefox.desktop[3462]: Gdk-Message: 10:01:47.701: /usr/lib64/firefox/firefox: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Jan 07 10:01:47 localhost.localdomain org.gnome.Shell.desktop[3462]: xcb_connection_has_error() returned true Jan 07 10:01:47 localhost.localdomain firefox.desktop[3462]: Sandbox: Unexpected EOF, op 2 flags 00 path /etc/localtime Jan 07 10:01:47 localhost.localdomain firefox.desktop[3462]: Sandbox: Unexpected EOF, op 2 flags 00 path /etc/localtime
(In reply to Jesper Skov from comment #11) > Hope the below is more informative. If not, let me know how I can help you. > [...] humm, not really, sorry. Could you upload the actual core file from Xwayland somewhere? that'd be our best chance, I reckon...
Sure. Where do I find it? Do I need to do something special to generate it?
From “coredumpctl list”, for the “EXE” /usr/bin/Xwayland, does the column “COREFILE” mention "present" or "missing"? If “present” you can attach gdb using “coredumpctl gdb <pid>” and from gdb save the core file with “generate-core-file”. Another possibility is to check if “abrt” captured it, if so it would be in the relevant /var/spool/abrt/ccpp* directory for the crash and named as “coredump”. Note that both coredumpctl and abrt will clean up and remove the corefiles pretty soon after the crash was captured.
Sorry for being lame (many many years since I worked linux native) I can start gdb, but cannot generate core, as it is not connected to a process: Core was generated by `/usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 -d'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 return ret; [Current thread is 1 (Thread 0x7fb01dc06ac0 (LWP 3515))] Missing separate debuginfos, use: dnf debuginfo-install llvm-libs-7.0.0-2.fc29.x86_64 sssd-client-2.0.0-5.fc29.x86_64 systemd-libs-239-7.git3bf819c.fc29.x86_64 xz-libs-5.2.4-3.fc29.x86_64 (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007fb01e331895 in __GI_abort () at abort.c:79 #2 0x0000559e1bef7ea0 in OsAbort () at utils.c:1350 #3 0x0000559e1befd139 in AbortServer () at log.c:879 #4 0x0000559e1befdfad in FatalError (f=f@entry=0x559e1bf22db0 "Caught signal %d (%s). Server aborting\n") at log.c:1017 #5 0x0000559e1bef51a5 in OsSigHandler (unused=<optimized out>, sip=<optimized out>, signo=11) at osinit.c:156 #6 OsSigHandler (signo=11, sip=<optimized out>, unused=<optimized out>) at osinit.c:110 #7 <signal handler called> #8 0x00007fb01e4d0470 in main_arena () from /lib64/libc.so.6 #9 0x0000559e1be5deae in proc_present_query_capabilities (client=0x559e1d4bd2b0) at present_request.c:236 #10 0x0000559e1bebf24e in Dispatch () at dispatch.c:478 #11 0x0000559e1bec32a6 in dix_main (argc=12, argv=0x7fff02545bb8, envp=<optimized out>) at main.c:276 #12 0x00007fb01e333413 in __libc_start_main (main=0x559e1bd91320 <main>, argc=12, argv=0x7fff02545bb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff02545ba8) at ../csu/libc-start.c:308 #13 0x0000559e1bd9135e in _start () at present_request.c:346 (gdb) generate-core-file /tmp/foo You can't do that without a process to debug.
Oh, and this was from a recent dump (the only one on disk). The stack trace does not look like the original one - not sure if that is because this is a different problem.
(In reply to Jesper Skov from comment #15) > (gdb) bt > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007fb01e331895 in __GI_abort () at abort.c:79 > #2 0x0000559e1bef7ea0 in OsAbort () at utils.c:1350 > #3 0x0000559e1befd139 in AbortServer () at log.c:879 > #4 0x0000559e1befdfad in FatalError (f=f@entry=0x559e1bf22db0 "Caught > signal %d (%s). Server aborting\n") at log.c:1017 > #5 0x0000559e1bef51a5 in OsSigHandler (unused=<optimized out>, > sip=<optimized out>, signo=11) at osinit.c:156 > #6 OsSigHandler (signo=11, sip=<optimized out>, unused=<optimized out>) at > osinit.c:110 > #7 <signal handler called> > #8 0x00007fb01e4d0470 in main_arena () from /lib64/libc.so.6 > #9 0x0000559e1be5deae in proc_present_query_capabilities > (client=0x559e1d4bd2b0) at present_request.c:236 > #10 0x0000559e1bebf24e in Dispatch () at dispatch.c:478 > #11 0x0000559e1bec32a6 in dix_main (argc=12, argv=0x7fff02545bb8, > envp=<optimized out>) at main.c:276 > #12 0x00007fb01e333413 in __libc_start_main (main=0x559e1bd91320 <main>, > argc=12, argv=0x7fff02545bb8, init=<optimized out>, fini=<optimized out>, > rtld_fini=<optimized out>, stack_end=0x7fff02545ba8) at > ../csu/libc-start.c:308 > #13 0x0000559e1bd9135e in _start () at present_request.c:346 I think this is the problem, much better than the automatically self-generated backtrace. > I can start gdb, but cannot generate core, as it is not connected to a > process: right my bad... You should be able to save the core file with “-o”, e.g.: coredumpctl -o Xwayland.core dump /usr/bin/Xwayland
Oh, and comment 8 mentions you're using xorg-x11-server-Xwayland-1.20.3-1.fc29. Can you please confirm the version? Reason I ask is because xorg-x11-server-Xwayland-1.20.3-2.fc29 contains severa lfixes backported from master for Present support in Xwayland.
#8 was from an earlier crash. The current package is xorg-x11-server-Xwayland-1.20.3-2.fc29.x86_64 - and I am pretty sure I rebooted after last update (even so, the crash should cause the new process to load latest image, no?) I will reboot after this to be sure. I uploaded core dump here: https://drive.google.com/file/d/19DzRruN6c4v5PZo0zxIe9Z3sGl5W3H_T/view?usp=sharing Let me know if you need more. Happy to help.
(In reply to Jesper Skov from comment #19) > #8 was from an earlier crash. > > The current package is xorg-x11-server-Xwayland-1.20.3-2.fc29.x86_64 - and I > am pretty sure I rebooted after last update (even so, the crash should cause > the new process to load latest image, no?) > I will reboot after this to be sure. No need, the core file is from 1.20.3-2 (from the build-id)
Can you try this scratch build to see if that helps? https://koji.fedoraproject.org/koji/taskinfo?taskID=31892117
I have updated the RPMs and restarted. I have no sure way of reproducing, but it usually happens a couple of times a day. Will update here when I know more.
Good morning, Olivier I think the new build fixes the problem in wayland. I had another crash yesterday, but this time it took down gnome-shell (same "input" conditions: external monitor switching). Backtrace looks like this (already reported in #1662913): Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f95e78c9306 in meta_window_maximize_internal () from /lib64/libmutter-3.so.0 [Current thread is 1 (Thread 0x7f95e3bb7d00 (LWP 3410))] Missing separate debuginfos, use: dnf debuginfo-install gnome-shell-3.30.2-1.fc29.x86_64 (gdb) bt #0 0x00007f95e78c9306 in meta_window_maximize_internal () from /lib64/libmutter-3.so.0 #1 0x00007f95e78cdb4b in meta_window_maximize () from /lib64/libmutter-3.so.0 #2 0x00007f95e6bf9ace in ffi_call_unix64 () at ../src/x86/unix64.S:76 #3 0x00007f95e6bf948f in ffi_call (cif=cif@entry=0x7ffde9802ca0, fn=<optimized out>, rvalue=<optimized out>, rvalue@entry=0x0, avalue=avalue@entry=0x7ffde9802d70) at ../src/x86/ffi64.c:525 #4 0x00007f95e4be031d in wl_closure_invoke (closure=closure@entry=0x56062ffeee30, flags=flags@entry=2, target=<optimized out>, target@entry=0x56063135e5f0, opcode=opcode@entry=9, data=<optimized out>, data@entry=0x560631bb41b0) at src/connection.c:1006 #5 0x00007f95e4bdcc69 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x560631bb41b0) at src/wayland-server.c:420 #6 0x00007f95e4bde2e2 in wl_event_loop_dispatch (loop=0x56062fba8f80, timeout=<optimized out>) at src/event-loop.c:641 #7 0x00007f95e78f41db in ?? () from /lib64/libmutter-3.so.0 #8 0x00007f95e845306d in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #9 0x00007f95e8453438 in ?? () from /lib64/libglib-2.0.so.0 #10 0x00007f95e8453762 in g_main_loop_run () from /lib64/libglib-2.0.so.0 #11 0x00007f95e78ba870 in meta_run () from /lib64/libmutter-3.so.0 #12 0x000056062fb02b96 in ?? () #13 0x00007f95e7633413 in __libc_start_main (main=0x56062fb02830, argc=1, argv=0x7ffde9803328, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffde9803318) at ../csu/libc-start.c:308 #14 0x000056062fb02cee in ?? () (gdb) If you do not mind, I would like to soak your build another day or two before we close this issue?
Just had another crash in gnome-shell like the above.
Yeap, but it's not Xwayland so different issue... I updated bug 1662913 because it's actually mutter. not gnome-shell. I'd rather keep the discussion about that bug in mutter in the dedicated bug to avoid confusion.
xorg-x11-server-1.20.3-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f379cf5a07
xorg-x11-server-1.20.3-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f379cf5a07
xorg-x11-server-1.20.3-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.