[PATCH weston] compositor-wayland: Fix a use after free

[Dima Ryazanov]

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.

Thanks!


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
> compositor-x11),
> > 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?
>
> Cheers,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161124/25330255/attachment.html>