Weston segfaults in a call to pixman_region32_contains_point() made from weston_compositor_pick_surface() and originating from destroy_resource() (see attached gdb backtrace). This happens when selecting "close" from the weston client context menu and moving the mouse after a split second of selecting the "close" option. It is somewhat tricky to reproduce due to the timing of the mouse move after clicking "close". I am able to reproduce with weston-terminal the easiest. wayland (master) heads/master-0-g7094441 fontconfig (master) heads/master-0-gcd9b103 drm (master) heads/master-0-ga0178c0 mesa (master) heads/master-0-gbbd2d57 libxkbcommon (master) heads/master-0-g6f06eb5 pixman (master) heads/master-0-g279bdcd cairo (master) heads/master-0-gb7331f0 weston (master) heads/master-0-ga58290b
Created attachment 81138 [details] weston segfault gdb backtrace
Created attachment 81374 [details] backtrace with weston compiled with ASAN An additionnal backtrace, the test case is the same: open weston-terminal, click on the close button, and go over the dying surface with the mouse pointer. The backtrace is generated with the RDP compositor and weston compiled with clang+ASAN.
(In reply to comment #2) > Created attachment 81374 [details] > backtrace with weston compiled with ASAN > > An additionnal backtrace, the test case is the same: open weston-terminal, > click on the close button, and go over the dying surface with the mouse > pointer. > The backtrace is generated with the RDP compositor and weston compiled with > clang+ASAN. This backtrace is quite different and isn't related to the issue above.
(In reply to comment #3) > (In reply to comment #2) > > Created attachment 81374 [details] > > backtrace with weston compiled with ASAN > > > > An additionnal backtrace, the test case is the same: open weston-terminal, > > click on the close button, and go over the dying surface with the mouse > > pointer. > > The backtrace is generated with the RDP compositor and weston compiled with > > clang+ASAN. > > This backtrace is quite different and isn't related to the issue above. Perhaps this backtrace is more related to https://bugs.freedesktop.org/show_bug.cgi?id=66198? Nonetheless, they are all encountered during similar use-cases.
commit 27b1793857953927f842065a57cb5821a86bc671 Author: Rob Bradford <rob@linux.intel.com> Date: Wed Jun 26 18:08:46 2013 +0100 compositor: rebuild the global list if we've removed a surface from it The list of surfaces used by weston_compositor_pick_surface() is maintained in list of surfaces stored on the compositor. This list is generated from the surfaces across all the layers using weston_compositor_build_surface_list. When destroying a surface the surface is "unmapped" with weston_surface_unmap which removes it from the layer list. However since the compositor surface list was only being rebuilt when the output was repainted a call to weston_compositor_pick_surface before the next output repaint would use an outdated surface list containing surfaces that have been partially destroyed. https://bugs.freedesktop.org/show_bug.cgi?id=65986 https://bugs.freedesktop.org/show_bug.cgi?id=66173 https://bugs.freedesktop.org/show_bug.cgi?id=66198
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.