[PATCH weston] compositor-wayland: Fix a use after free
dima at gmail.com
Thu Nov 24 13:07:45 UTC 2016
Oh damn, I was looking for an API to cancel a callback and couldn't find
anything; didn't realize all I needed to do is destroy it. That makes it so
much simpler. I'll send out a follow-up patch.
On Thu, Nov 24, 2016 at 4:05 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Dima,
> On 24 November 2016 at 06:07, Dima Ryazanov <dima at gmail.com> wrote:
> > When a window is being closed, the frame_done callback often runs after
> > the output is already destroyed, i.e:
> > wayland_output_start_repaint_loop
> > input_handle_button
> > wayland_output_destroy
> > frame_done
> > To fix this, destroy the output from an idle handler (same as
> > and also stop creating new frame_done callbacks.
> Hm. The reason for moving destroy to an idle handler in X11, is that
> handle_event may be called 'in the middle of repaint'. I suspect - and
> Derek, please correct me if I'm wrong - that this was because we may
> start the X11 repaint loop, send a request, await a reply, and whilst
> waiting for that reply, receive a DELETE_WINDOW event which causes us
> to delete. Which would be bad.
> If that's right, then it's a different root cause. We'll never
> dispatch any Wayland events during repaint; we don't do so ourselves,
> and the only thing that could cause to is EGL, which must only be
> dispatching on its own separate event queue.
> So, if the root cause is the frame callback arriving after destroy:
> why not just destroy the frame callback, so we never receive it, and
> can destroy immediately?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel