Created attachment 93555 [details]
Weston GDB Backtrace
wl_shm_pool_resize crashes weston if a wl_buffer from the pool is attached to a surface and the new size is smaller.
It looks like weston is trying to access memory outside of the new pool size because it was attached with the old size. Maybe there should be a check if the pool associated with the buffer has changed.
Yikes. Yes, the client behavior you describe is an application bug, in that it is reusing/destroying the buffer's storage without waiting for a wl_buffer.release, right? Also the client should destroy the wl_buffer before invalidating its storage.
But this client bug also exposes a weston bug in that weston really should not crash here.
Actually this needs to be fixed in libwayland-server, because the wl_shm_pool_resize is handled there. I'd prefer to send a fatal error to the client immediately when a resize attempts invalidate the storage of any existing wl_buffer, rather than check on use. We may also want to add a note of this in the protocol spec.
A simpler alternative would be to specify that resize must never make the size smaller. I am unsure which one would be preferable.
Therefore I am changing the component to "wayland", on a quick glance I do not see anything needing fixing in Weston code.
Thanks for reporting this.
(I'm only analyzing this one for now, not assigning it to myself.)
Author: Kristian Høgsberg <email@example.com>
Date: Mon Apr 7 14:42:20 2014 -0700
shm: Disallow shrinking shm pools
Unused shm space will be automatically reclaimed if unused or can be
explicitly returned by using fallocate FALLOC_FL_PUNCH_HOLE.