When a window is closed, Weston will, by default, run a fade out animation and defer destroying the underlying surface until it completes. However, if the compositor is sleeping, and therefore not rendering any frames, this animation will *never* complete. Therefore, if windows are repeatedly created and destroyed while in sleep mode, these surfaces will keep accumulating, and since the buffers attached to them may be backed by an fd, eventually the ulimit will be reached resulting in a potential crash or other errors. This can be demonstrated repeatedly launching and killing an X11 application with Xwayland running. while true; do xterm & pid=$!; sleep 0.5; kill $pid; done As soon as the compositor goes to sleep, one can observe a steadily growing list of dmabufs in the output of lsof. As a fix, desktop_surface_removed should check whether the compositor is active before kicking off the fade animation. If it is not, it should instead drop the extra reference taken in desktop_surface_committed and then destroy the surface immediately. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>dev
parent
eb34f827dd
commit
04918f3b0b
Loading…
Reference in new issue