<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - VT switching crashes Xwayland and weston" href="https://bugs.freedesktop.org/show_bug.cgi?id=79609#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - VT switching crashes Xwayland and weston" href="https://bugs.freedesktop.org/show_bug.cgi?id=79609">bug 79609</a> from <a class="email" href="mailto:calcmogul@gmail.com" title="Tyler Veness <calcmogul@gmail.com>"> Tyler Veness</a> <pre>I noticed this myself and have been trying to track down the problem for two days now. I've been working off of the lastest commit to master in xserver as of yesterday. My backtrace of Weston is as follows: Weston backtrace: #0 0x00007fe832fb7b26 in wl_event_loop_add_idle (loop=0x0, func=0x7fe82c3010b9 <weston_wm_window_draw_decoration>, data=0x2670210) at src/event-loop.c:301 #1 0x00007fe82c301514 in weston_wm_window_schedule_repaint (window=0x2670210) at xwayland/window-manager.c:1045 #2 0x00007fe82c30099f in weston_wm_window_activate (listener=0x266f290, data=0x26f9cf0) at xwayland/window-manager.c:727 #3 0x0000000000411bd6 in wl_signal_emit (signal=0x25e93e8, data=0x26f9cf0) at /usr/include/wayland-server.h:260 #4 0x0000000000414124 in weston_surface_activate (surface=0x26f9cf0, seat=0x2669100) at src/input.c:1009 #5 0x00007fe82c520570 in activate (shell=0x25ebdf0, es=0x26f9cf0, seat=0x2669100, configure=true) at desktop-shell/shell.c:4578 #6 0x00007fe82c518344 in focus_state_surface_destroy (listener=0x2a8b560, data=0x2ad02e0) at desktop-shell/shell.c:695 #7 0x0000000000407b93 in wl_signal_emit (signal=0x2ad02e8, data=0x2ad02e0) at /usr/include/wayland-server.h:260 #8 0x000000000040b3f3 in weston_surface_destroy (surface=0x2ad02e0) at src/compositor.c:1406 #9 0x00007fe82c51db47 in fade_out_done (animation=0x26f5c10, data=0x2ad04d0) at desktop-shell/shell.c:3199 #10 0x000000000041e1a8 in weston_view_animation_destroy (animation=0x26f5c10) at src/animation.c:143 #11 0x000000000041e27d in weston_view_animation_frame (base=0x26f5c18, output=0x2687020, msecs=28460436) at src/animation.c:174 #12 0x000000000040c67a in weston_output_repaint (output=0x2687020, msecs=28460436) at src/compositor.c:1832 #13 0x000000000040c760 in weston_output_finish_frame (output=0x2687020, msecs=28460436) at src/compositor.c:1861 #14 0x00007fe83159285f in page_flip_handler (fd=12, frame=425573, sec=28460, usec=436680, data=0x2687020) at src/compositor-drm.c:761 #15 0x00007fe830d68e6e in drmHandleEvent () from /usr/lib/libdrm.so.2 #16 0x00007fe831593d81 in on_drm_input (fd=12, mask=1, data=0x25e9360) at src/compositor-drm.c:1259 #17 0x00007fe832fb756b in wl_event_source_fd_dispatch (source=0x2690a50, ep=0x7fff913542bc) at src/event-loop.c:86 #18 0x00007fe832fb7f19 in wl_event_loop_dispatch (loop=0x25e0220, timeout=-1) at src/event-loop.c:419 #19 0x00007fe832fb5d10 in wl_display_run (display=0x25e0190) at src/wayland-server.c:969 #20 0x0000000000411a71 in main (argc=1, argv=0x7fff91354768) at src/compositor.c:4378 weston passes in wm->server->loop from a weston_wm* to wayland's wl_event_loop_add_idle(). wayland dereferences some members from it and segfaults. I applied the patch in my first attachment to wayland to study the problem further. I also got a backtrace of XWayland but with line numbers as well: XWayland backtrace: #0 0x000000000046ffd6 in miPointerSetCursorPosition (pDev=0x2c94350, pScreen=0x27f42b0, x=33, y=167, generateEvent=1) at mipointer.c:264 #1 0x0000000000514aa6 in AnimCurSetCursorPosition (pDev=0x2c94350, pScreen=0x27f42b0, x=33, y=167, generateEvent=1) at animcur.c:245 #2 0x000000000042f742 in pointer_handle_enter (data=0x2b0abe0, pointer=0x2cc85d0, serial=43, surface=0x2cb4a90, sx_w=8635, sy_w=42824) at xwayland-input.c:160 #3 0x00007f1572748df0 in ffi_call_unix64 () from /usr/lib/libffi.so.6 #4 0x00007f1572748861 in ffi_call () from /usr/lib/libffi.so.6 #5 0x00007f15741ac382 in wl_closure_invoke (closure=0x2c92ac0, flags=1, target=0x2cc85d0, opcode=0, data=0x2b0abe0) at src/connection.c:934 #6 0x00007f15741a98e6 in dispatch_event (display=0x27f4970, queue=0x27f4a58) at src/wayland-client.c:1054 #7 0x00007f15741a9b41 in dispatch_queue (display=0x27f4970, queue=0x27f4a58) at src/wayland-client.c:1159 #8 0x00007f15741a9e7d in wl_display_dispatch_queue_pending (display=0x27f4970, queue=0x27f4a58) at src/wayland-client.c:1381 #9 0x00007f15741a9ee5 in wl_display_dispatch_pending (display=0x27f4970) at src/wayland-client.c:1458 #10 0x000000000042e53e in wakeup_handler (data=0x27f4800, err=1, read_mask=0x879000 <LastSelectMask>) at xwayland.c:419 #11 0x00000000005adc02 in WakeupHandler (result=1, pReadmask=0x879000 <LastSelectMask>) at dixutils.c:423 #12 0x00000000005ed01b in WaitForSomething (pClientsReady=0x2c9ad40) at WaitFor.c:229 #13 0x000000000059ebf2 in Dispatch () at dispatch.c:361 #14 0x00000000005acee2 in dix_main (argc=10, argv=0x7fff421f5c98, envp=0x7fff421f5cf0) at main.c:296 #15 0x000000000058f261 in main (argc=10, argv=0x7fff421f5c98, envp=0x7fff421f5cf0) at stubmain.c:34 This was another case of null pointers. I fixed all of them with the patch in my second attachment. XWayland no longer crashed, but X windows would no longer accept mouse input or be draggable due to the patch's change to hw/xwayland/xwayland-input.c. With that patch applied, the first one technically isn't needed, but should be included as a safeguard (the compositor shouldn't be able to break Wayland so easily). Maybe an assert would be better there so devs know if they broke things? I traced the call to the MIPOINTER(pDev) macro made at mi/mipointer.c:262 and found that IsFloating(pDev) returns true, so the mouse pointer is a floating device. This lead to "dixLookupPrivate(&(dev)->devPrivates, miPointerPrivKey)" being called from the macro, which calls "dixGetPrivate" (include/privates.h:134), which returns "*(void **) dixGetPrivateAddr(privates, key)" (include/privates.h:120). This essentially returns "(char *) (*privates) + key->offset" dereferenced, which is NULL. My third attachment contains a printout from GDB of the values in the struct from the DeviceIntPtr pDev located in the function miPointerDisplayCursor:193 in mi/mipointer.c. The values contained by the DeviceIntPtr don't fix themselves so the mouse input stays broken for X windows. Native Wayland apps still accepted keyboard and mouse input properly.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>