XWayland crashes on mouse input

faithanalog commented 8 years ago

XWayland is segfaulting on mouse movement, and key input does not work. I experienced this both in velox, and in my own WM, which is at the moment nearly identical to example/wm.c. I am running on arch linux using the latest version of swc, velox, and wld (just built it from source).

Here is the corresponding log file from running velox, launching urxvt, and moving the mouse. https://gist.github.com/unknownloner/53d16807df0360161002

I have tested both weston and wlc (another compositor library), and neither of them have this issue. Additionally, this only affects xwayland. Normal wayland programs run fine.

swc itself does not freeze; I am able to terminate normally using my quit keybind. However, whatever WM program was launched with swc-launch will start running at 100% cpu until swc exits.

There is a certain condition which will sometimes prevent this segfault. If swc-launch is told to launch on a TTY which is not the TTY that the command is being run from, and if either stdout or stderr is redirected to a file, xwayland may act normally. The output must be redirected to an actual file, /dev/null will not work. I have not been able to get these to work 100% of the time, but perhaps it'll provide a clue as to what the problem is?

These sometimes work for me: swc-launch -t /dev/tty3 velox > derp

swc-launch -t /dev/tty3 velox 2> derp

These have always crashed for me: swc-launch -t /dev/tty3 velox

swc-launch velox > derp

swc-launch -t /dev/tty3 velox > /dev/null

This has also always crashed for me if run from tty3 (so launching does not result in a TTY change). swc-launch -t /dev/tty3 velox > derp

This seems to be a separate issue from #14

michaelforney commented 8 years ago

Since it is Xwayland that is crashing, could you try to obtain a backtrace of Xwayland? Perhaps the best way to do this is to build Xwayland manually with debugging symbols, and then modify libswc/xserver.c to launch

gdb -batch -ex run -ex back --args Xwayland ...

Alternatively, you could add an Xwayland script

#!/bin/sh
gdb -batch -ex run -ex back --args /path/to/xserver/hw/xwayland/Xwayland "$@"

and put it somewhere in your path before your system Xwayland.

elkx1 commented 8 years ago

I am also experiencing this issue.

Just running stock Xwayland (from package manager) in gdb yielded a largely useless stack trace, so I've compiled a debug version. I also had to print out the pid of the forked process from xserver.c and attach to it with gdb -p, because it wasn't working with gdb -ex run for some reason.

The resulting stack trace is as follows:

Program received signal SIGSEGV, Segmentation fault.
miPointerSetCursorPosition (pDev=0x257e120, pScreen=0x22bbc60, x=792, y=434, generateEvent=1) at mipointer.c:264
264         pPointer->generateEvent = generateEvent;
(gdb) bt
#0  miPointerSetCursorPosition (pDev=0x257e120, pScreen=0x22bbc60, x=792, y=434, generateEvent=1) at mipointer.c:264
#1  0x00000000004ca483 in AnimCurSetCursorPosition (pDev=<optimized out>, pScreen=0x22bbc60, x=<optimized out>, y=<optimized out>, generateEvent=<optimized out>) at animcur.c:245
#2  0x0000000000431615 in pointer_handle_enter (data=0x23f0000, pointer=<optimized out>, serial=<optimized out>, surface=<optimized out>, sx_w=<optimized out>, sy_w=111104) at xwayland-input.c:178
#3  0x00007f0eebc84dc0 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#4  0x00007f0eebc84828 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#5  0x00007f0eed9ce52d in ?? () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#6  0x00007f0eed9cb86b in ?? () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#7  0x00007f0eed9cb8ec in ?? () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#8  0x00007f0eed9cc5f4 in wl_display_dispatch_queue_pending () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#9  0x000000000042fc93 in wakeup_handler (data=0x22bc1b0, err=<optimized out>, read_mask=<optimized out>) at xwayland.c:439
#10 0x000000000052fadb in WakeupHandler (result=result@entry=1, pReadmask=pReadmask@entry=0x7e5480 <LastSelectMask>) at dixutils.c:423
#11 0x000000000055b9a5 in WaitForSomething (pClientsReady=pClientsReady@entry=0x25783c0) at WaitFor.c:229
#12 0x000000000052ae10 in Dispatch () at dispatch.c:359
#13 0x000000000052efa3 in dix_main (argc=10, argv=0x7ffe11820688, envp=<optimized out>) at main.c:300
#14 0x00007f0eec0bab45 in __libc_start_main (main=0x42f800 <main>, argc=10, argv=0x7ffe11820688, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe11820678)
    at libc-start.c:287
#15 0x000000000042f82e in _start ()

michaelforney commented 8 years ago

This sounds a lot like https://bugs.freedesktop.org/show_bug.cgi?id=81819. Can you try applying http://lists.x.org/archives/xorg-devel/2014-August/043432.html to your Xwayland and see if that fixes the issue?

elkx1 commented 8 years ago

I have applied the patch you mentioned and can confirm that this does indeed fix the issue. In fact, I am writing this comment from Firefox running in velox via Xwayland!

Now that I can move the mouse, though, there seems to be another issue: the cursor is only changed once, when an application starts up for the first time or when I switch vts between the one on which the compositor is running and another. Mousing over things that would normally change the cursor has no effect. Do you think this is a related issue?

michaelforney commented 8 years ago

The fix was merged into xserver master, so closing this.

michaelforney / swc

XWayland crashes on mouse input #31