Description of problem: start Wayland session using a device with touch screen (I use a laptop) play any video using smplayer with mpv backend touch smplayer seek bar Wayland session crashes and Fedora goes to login screen Version-Release number of selected component: xorg-x11-server-Xwayland-1.19.5-1.fc27 Additional info: reporter: libreport-2.9.2 crash_function: OsLookupColor executable: /usr/bin/Xwayland kernel: 4.13.9-300.fc27.x86_64 runlevel: N 5 type: xorg uid: 0 Truncated backtrace: 0: /usr/bin/Xwayland (OsLookupColor+0x139) [0x591c49] 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7fe66518aabf] 2: /usr/bin/Xwayland (Ones+0x208) [0x54e4f8] 3: /usr/bin/Xwayland (SendErrorToClient+0x368) [0x557ee8] 4: /usr/bin/Xwayland (InitFonts+0x420) [0x55bf10] 5: /lib64/libc.so.6 (__libc_start_main+0xea) [0x7fe664db403a] 6: /usr/bin/Xwayland (_start+0x2a) [0x422a3a] Potential duplicate: bug 1498858
Created attachment 1361210 [details] File: backtrace
Created attachment 1361211 [details] File: cpuinfo
Created attachment 1361212 [details] File: dmesg
Created attachment 1361213 [details] File: dso_list
Created attachment 1361214 [details] File: etc_X11_xorg_conf_d.tar.gz
Created attachment 1361215 [details] File: usr_share_xorg_conf_d.tar.gz
Unfortunately, the backtrace doesn't tell us much, appart that the crash occurs in ProcGetMotionEvents() at dix/devices.c:2384 (i.e. calling dixLookupWindow()). 2370 int 2371 ProcGetMotionEvents(ClientPtr client) 2372 { 2373 WindowPtr pWin; 2374 xTimecoord *coords = (xTimecoord *) NULL; 2375 xGetMotionEventsReply rep; 2376 int i, count, xmin, xmax, ymin, ymax, rc; 2377 unsigned long nEvents; 2378 DeviceIntPtr mouse = PickPointer(client); 2379 TimeStamp start, stop; 2380 2381 REQUEST(xGetMotionEventsReq); 2382 REQUEST_SIZE_MATCH(xGetMotionEventsReq); 2383 2384 rc = dixLookupWindow(&pWin, stuff->window, client, DixGetAttrAccess); 2385 if (rc != Success) 2386 return rc; 2387 rc = XaceHook(XACE_DEVICE_ACCESS, client, mouse, DixReadAccess); 2388 if (rc != Success) 2389 return rc; 2390
Could you post the result of "xinput list"?
Actually, I managed to reproduce a crash within a few seconds using evemu to emulate a touchscreen (I don't have any device with a touchscreen). So I am quite convinced this is related to the touch device somehow. Funny thing (if I may) is that I had two crashes, one in in Xwayland (similar to this one) and another one some other time in gnome-shell/mutter instead, also pointing toward the touch device: Process 2585 (gnome-shell) of user 1000 dumped core. Stack trace of thread 2585: #0 0x00007f56040af90b raise (libpthread.so.0) #1 0x000055f5e89fda0b dump_gjs_stack_on_signal_handler (gnome-shell) #2 0x00007f56040afa70 __restore_rt (libpthread.so.0) #3 0x00007f5603cef69b __GI_raise (libc.so.6) #4 0x00007f5603cf13b1 __GI_abort (libc.so.6) #5 0x00007f5605e5169d g_assertion_message (libglib-2.0.so.0) #6 0x00007f5605e5172a g_assertion_message_expr (libglib-2.0.so.0) #7 0x00007f560439ce51 touch_handle_surface_destroy (libmutter-1.so.0) #8 0x00007f55fa4aaea0 wl_priv_signal_emit (libwayland-server.so.0) #9 0x00007f55fa4aaf5c destroy_resource (libwayland-server.so.0) #10 0x00007f55fa4af7f9 wl_map_for_each (libwayland-server.so.0) #11 0x00007f55fa4ab01d wl_client_destroy (libwayland-server.so.0) #12 0x00007f55fa4ab0d8 wl_client_connection_data (libwayland-server.so.0) #13 0x00007f55fa4acc12 wl_event_loop_dispatch (libwayland-server.so.0) #14 0x00007f5604389947 wayland_event_source_dispatch (libmutter-1.so.0) #15 0x00007f5605e2abb7 g_main_dispatch (libglib-2.0.so.0) #16 0x00007f5605e2af60 g_main_context_iterate (libglib-2.0.so.0) #17 0x00007f5605e2b272 g_main_loop_run (libglib-2.0.so.0) #18 0x00007f560435b23c meta_run (libmutter-1.so.0) #19 0x000055f5e89fd42c main (gnome-shell) #20 0x00007f5603cd903a __libc_start_main (libc.so.6) #21 0x000055f5e89fd56a _start (gnome-shell)
xinput list out(In reply to Olivier Fourdan from comment #8) > Could you post the result of "xinput list"? ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ xwayland-pointer:13 id=6 [slave pointer (2)] ⎜ ↳ xwayland-relative-pointer:13 id=7 [slave pointer (2)] ⎜ ↳ xwayland-touch:13 id=9 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ xwayland-keyboard:13
Ok, I've some interesting findings... I can reliably cause Xwayland to crash in ProcGetPointerControl() with smplayer playing a video while emulating random touch events. The crash occurs in ProcGetPointerControl(): 2328 int 2329 ProcGetPointerControl(ClientPtr client) 2330 { 2331 DeviceIntPtr ptr = PickPointer(client); 2332 PtrCtrl *ctrl = &ptr->ptrfeed->ctrl; 2333 xGetPointerControlReply rep; 2334 int rc; 2335 2336 REQUEST_SIZE_MATCH(xReq); 2337 2338 rc = XaceHook(XACE_DEVICE_ACCESS, client, ptr, DixGetAttrAccess); 2339 if (rc != Success) 2340 return rc; 2341 2342 rep = (xGetPointerControlReply) { 2343 .type = X_Reply, 2344 .sequenceNumber = client->sequence, 2345 .length = 0, 2346 .accelNumerator = ctrl->num, 2347 .accelDenominator = ctrl->den, 2348 .threshold = ctrl->threshold 2349 }; 2350 WriteReplyToClient(client, sizeof(xGenericReply), &rep); 2351 return Success; 2352 } Because ptr->ptrfeed is NULL (funny thing, the crash actually occurs when trying to access ctrl->num, but I would blame it on a gcc optimization most likely - Fact is that ptr->ptrfeed in NULL) Adding a watch point in gdb, I could find out that ptr->ptrfeed is set to NULL just before by DeepCopyPointerClasses(): Thread 1 "Xwayland" hit Hardware watchpoint 1: *0x133fab0 Old value = 20206800 New value = 0 0x000000000053b379 in DeepCopyPointerClasses (to=0x133f9c0, from=0x15903d0) at exevents.c:527 527 to->ptrfeed = NULL; (gdb) bt #0 0x000000000053b379 in DeepCopyPointerClasses (to=0x133f9c0, from=0x15903d0) at exevents.c:527 #1 DeepCopyDeviceClasses (from=0x15903d0, to=to@entry=0x133f9c0, dce=dce@entry=0x7ffce4ccafa0) at exevents.c:672 #2 0x000000000053db8c in ChangeMasterDeviceClasses (device=0x133f9c0, dce=0x7ffce4ccafa0) at exevents.c:727 #3 0x000000000053ddc4 in UpdateDeviceState (device=0x133f9c0, event=0x7ffce4ccafa0) at exevents.c:807 #4 0x000000000053e249 in ProcessDeviceEvent (ev=ev@entry=0x7ffce4ccafa0, device=device@entry=0x133f9c0) at exevents.c:1709 #5 0x000000000053ea13 in ProcessOtherEvent (ev=0x7ffce4ccafa0, device=0x133f9c0) at exevents.c:1873 #6 0x000000000055f8af in ProcessPointerEvent (ev=0x7ffce4ccafa0, mouse=0x133f9c0) at xkbAccessX.c:756 #7 0x00000000004bfb23 in mieqProcessDeviceEvent (dev=0x15903d0, event=0x7ffce4ccbbf0, screen=0x974750) at mieq.c:496 #8 0x00000000004bfc81 in mieqProcessInputEvents () at mieq.c:551 #9 0x000000000042ed05 in ProcessInputEvents () at xwayland-input.c:2466 #10 0x000000000044400f in Dispatch () at dispatch.c:417 #11 0x00000000004481b8 in dix_main (argc=12, argv=0x7ffce4ccc9d8, envp=<optimized out>) at main.c:276 #12 0x00007facd327a03a in __libc_start_main (main=0x429710 <main>, argc=12, argv=0x7ffce4ccc9d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffce4ccc9c8) at ../csu/libc-start.c:308 #13 0x000000000042974a in _start () (gdb) cont
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.