I'm experiencing this with wayland head (1.4.91) as of submission of this bug(within a couple minutes) When I resize weston-simple-egl very small(probably fails with negative values), weston crashes. I'm limited in time for now, but what I can tell you is that it doesn't seem to be a backend-specific issue as it happens in both fbdev and drm backends. It could be a shell bug, as I've not been able to test other shells(I can't seem to find the old tablet shell, and it doesn't seem to be building the fullscreen shell). I'm sorry I can't provide more detail at the moment, and I haven't had the time to craft a non-GL client which resizes like weston-simple-egl.
What version of Mesa are you using? I think this bug should be fixed with the following commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6c9d6898fdfd7e23306762af9bf2501 It looks like that patch isn't in a released version of Mesa but is only in the master branch.
There's seem to be an issue that is independent of the Mesa patch. With the following patch, diff --git a/clients/window.c b/clients/window.c index e2f7010..da3e45d 100644 --- a/clients/window.c +++ b/clients/window.c @@ -3808,10 +3808,12 @@ window_schedule_resize(struct window *window, int width, int height) window->min_allocation.height = height; } +#if 0 if (window->pending_allocation.width < window->min_allocation.width) window->pending_allocation.width = window->min_allocation.width; if (window->pending_allocation.height < window->min_allocation.height) window->pending_allocation.height = window->min_allocation.height; +#endif window->resize_needed = 1; window_schedule_redraw(window); I get a crash trying to resize weston-terminal smaller than 0: #0 0x00007ffff7fea536 in wl_resource_post_event (resource=0x0, opcode=0) at wayland-server.c:154 #1 0x00007ffff33dc4bb in xdg_surface_send_configure (resource_=0x0, width=72, height=-1) at ./protocol/xdg-shell-server-protocol.h:438 #2 0x00007ffff33e2ff4 in xdg_send_configure (surface=0x7fd570, edges=5, width=72, height=-1) at desktop-shell/shell.c:3451 #3 0x00007ffff33df5a8 in resize_grab_motion (grab=0xa9b960, time=2830098011, x=307712, y=169984) at desktop-shell/shell.c:1620 #4 0x00000000004139d2 in notify_motion (seat=0x63bf70, time=2830098011, dx=512, dy=0) at src/input.c:948 #5 0x00007ffff68289af in x11_compositor_deliver_motion_event (c=0x63bbd0, event=0x7f70d0) at src/compositor-x11.c:1081 #6 0x00007ffff6828eb0 in x11_compositor_handle_event (fd=14, mask=0, data=0x63bbd0) at src/compositor-x11.c:1245 #7 0x00007ffff7fed454 in wl_event_source_fd_dispatch (source=0x760430, ep=0x7fffffffd6f0) at event-loop.c:86 #8 0x00007ffff7fedcf2 in post_dispatch_check (loop=0x63cd70) at event-loop.c:387 #9 0x00007ffff7fedea1 in wl_event_loop_dispatch (loop=0x63cd70, timeout=0) at event-loop.c:427 #10 0x000000000040c2cd in weston_output_repaint (output=0x683c80, msecs=2830098004) at src/compositor.c:1810 #11 0x000000000040c48a in weston_output_finish_frame (output=0x683c80, msecs=2830098004) at src/compositor.c:1848 #12 0x00007ffff6826d2d in x11_output_start_repaint_loop (output=0x683c80) at src/compositor-x11.c:347 #13 0x00007ffff682728f in finish_frame_handler (data=0x683c80) at src/compositor-x11.c:457 #14 0x00007ffff7fed6df in wl_event_source_timer_dispatch (source=0x676240, ep=0x7fffffffda80) at event-loop.c:180 #15 0x00007ffff7fede6a in wl_event_loop_dispatch (loop=0x6309e0, timeout=-1) at event-loop.c:421 #16 0x00007ffff7febbe2 in wl_display_run (display=0x630950) at wayland-server.c:961 #17 0x0000000000411536 in main (argc=1, argv=0x7fffffffdf08) at src/compositor.c:4296 The problem is that even though the client exists, the resize grab remains active. When the cursor moves, it attempts to send a configure event to the client, but the resource was destroyed and the pointer to it was set to NULL in the destroy listener for the shell surface resource. A simple fix would be to just check if shsurf->resource is non-NULL in resize_grab_motion, however it would probably be better to make sure we end the grab when the shell surface is destroyed.
commit 9c376b54ea6f60ae10d93653132e22ef66a536d7 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 29 17:54:03 2014 +0300 shell: Fix crash when a client is destroyed during the resize grab If a client exists during a resize grab, the resource for the shell surface being resized is destroyed. The shell surface is not destroyed immediately, however, because of the window close animation. In that case, the compositor would crash trying to send configure events to the surface being resized, since it would pass a NULL pointer to wl_resource_post_event(). The code for the resize grab was already able to handle the surface going away, so expand it to also handle the resource going away and fix the crash. https://bugs.freedesktop.org/show_bug.cgi?id=77344
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.