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.)
commit 24cdbe3d69763708dcd156edfbe7aa8d00bab860 Author: Kristian Høgsberg <krh@bitplanet.net> 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. https://bugs.freedesktop.org/show_bug.cgi?id=74632
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.