Bug 46450

I can reliably crash Weston using the dnd demo as follows:

• Launching clients/dnd;
• Dragging two flowers onto another flower;
• Unfocus, then refocus, the DND test app's window (otherwise it doesn't respond to right clicks);
• Right click it and choose Close.

The backtrace I see is a little different to zhao jian's:

#0  0x00007ffff79d8157 in wl_list_remove (elm=0x9237e8) at ../../src/wayland-util.c:50
#1  0x0000000000408e39 in weston_surface_unmap (surface=0x923720)
    at ../../src/compositor.c:607
#2  0x0000000000408eac in destroy_surface (resource=0x923720)
    at ../../src/compositor.c:627
#3  0x00007ffff79d84b9 in for_each_helper (data=0x7fffffffdeec, 
    func=0x7ffff79d3db0 <destroy_resource>, entries=<optimized out>)
    at ../../src/wayland-util.c:264
#4  wl_map_for_each (map=0x886338, func=0x7ffff79d3db0 <destroy_resource>, 
    data=0x7fffffffdeec) at ../../src/wayland-util.c:270
#5  0x00007ffff79d4402 in wl_client_destroy (client=0x886300)
    at ../../src/wayland-server.c:420
#6  0x00007ffff79d4541 in wl_client_connection_data (fd=<optimized out>, 
    mask=<optimized out>, data=0x886300) at ../../src/wayland-server.c:260
#7  0x00007ffff79d6962 in wl_event_loop_dispatch (loop=0x616900, timeout=<optimized out>)
    at ../../src/event-loop.c:462
#8  0x00007ffff79d4d7d in wl_display_run (display=0x6168b0)
    at ../../src/wayland-server.c:847
#9  0x000000000040677f in main (argc=<optimized out>, argv=<optimized out>)
    at ../../src/compositor.c:2583

The crashing line is

50		elm->prev->next = elm->next;

which segfaults because prev (and, for that matter, next) are NULL.

Throwing in some breakpoints shows that weston_surface_unmap() gets called for the crashing surface twice: first after ending a drag, and second when the window is closed.

Immediately after the first call, there is a final call to weston_surface_assign_output() on the surface, which re-sets ->output on the surface but does not re-attach it to a list. But the call to weston_surface_unmap() in destroy_surface() is guarded by checking ->output, so…

(In reply to comment #1)
> • Dragging two flowers onto another flower;

Sorry, this is not quite right: you have to drag one flower onto another, then drag that flower onto a third flower.

This looks to have been fixed by <http://cgit.freedesktop.org/wayland/weston/commit/?id=de56c311d94e6df37537b9e05ec72863906902ff>

It fixed in below System Environment.

wayland:             (master) 5b72fc7528aa9f7c655dd49a2227cfd1e3feeb76
libdrm:               (master) a3c34f56b94d4d47cadcd9814c2684c11f800e7d
macros:              (master) c0c42057e0d357c144e7933ee413b522950a0f17
glproto:              (master) 29d5b553b30755a25300c30b67d39b37c9a76466
dri2proto:            (master) 7fd18b15646a62bd82a4eb0eca60a34c1731813d
xproto:               (master) 20202784b9700d973d5301f0cb3243eba99fc349
libX11:               (master) abc523fce31fcf2687229697a8eb656e343ecb0c
mesa:                (master) 2402ce04ae06f909e361782f5063fa3070091bf1
kbproto:              (master) 391a1f6de6315fc0196d407d800597488315cccb
libxkbcommon:         (master) 3d672fcfea6b823db4793b9ad1c3aadc4b547a08
pixman:              (master) b9ca23a9c711280a706eb1df30a0cfaf3b2d8e27
cairo:                 (master) d18542b735bb777b444152f0ef06de18993635bd
weston:              (master) 3448616bc3909faa2d7d2c559be845085a1b23ab
kernel:               (drm-intel-next-queued) e7e58eb5c0d1d7d1a42fcb2b5a247d28ec08b47e

Verified. Fixed.