After display protocol error communication between wayland protocol and client is broken.

[Ikshwaku Chauhan]

Hello Pekka,

Thanks for your inputs and we are able to find further why we are getting
the "Protocol Error".
Please provide you inputs for below query:

As we are very frequently create and destroy surface, during this at one
instance "controller_surface_create" function from ivi-controller.c which
tries to create the wl_resources is not able to create the wl_resources,
because surface is already destroyed and this function returns without
creating the resources from below mentioned part of the function

    layout_surface = lyt->get_surface_from_id(id_surface);
    if (layout_surface == NULL) {
        return;
    }
So, here ivi-controller is not notifying any error event for this.
as per the ivi-controller.xml, ivi-controller have one error interface that
can be set, if any error encountered by ivi-controller interface.
Is there a way by which we can notify the client about the error?

Attaching ivi-controller.c file for reference.

Thanks in advance.

Regards,
Ikshwkau

On Tue, Jan 1, 2019 at 6:11 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Mon, 31 Dec 2018 20:08:24 +0530
> Ikshwaku Chauhan <ikshwaku.ec2004 at gmail.com> wrote:
>
> > Hello Pekka,
> >
> > Thanks for your reply.
> > Here we are trying to identify the exact root cause for the protocol
> error.
> > we deliberately dumped the back trace by calling *abort in
> > display_protocol_error* function and attaching backtrace for your
> > reference.
> > Could you please have a look and provide your inputs.
>
> Hi,
>
> sorry, I explained my guesses in my previous email, and if those
> are true, backtrace of the protocol error is not helpful. You need
> to look into when you create, skip creating, or destroy
> wl_resources representing ivi_controller_surface objects.
>
> The bug likely happens before the protocol error: when you are
> processing ivi_controller.surface_create or between that and a
> request that triggers the protocol error.
>
> > We have one more query,
> > As per the wayland client logs I have attached in the last mail, we
> > observed that after getting surface created event, usually we get
> > configuration event and then if we set any property of surface (ex:
> > set_source_rectangle), the protocol communication seems to be fine.
> > But, when surface created event received and without configuration event,
> > if we try to set any property of surface, the protocol communication
> seems
> > to be stuck.
>
> I suppose the compositor is not sending the configuration event for
> some reason? Maybe the underlying surface was destroyed immediately
> after it was created?
>
> That is not upstream Weston code, so I cannot know.
>
> > Is this the expected behavior for "Protocol error"?  Please provide you
> > inputs for this as well.
>
> As said, all protocol errors are instantly fatal and cause the
> Wayland connection to become dead. No further messaging will be
> possible on a dead connection.
>
> Events that have been written into the socket before the protocol
> error will remain, but the socket is already disconnected.
>
>
> Thanks,
> pq
>
> > On Sun, Dec 30, 2018 at 2:42 PM Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >
> > > If I had to guess, you have a compositor-side bug. Either the
> > > wl_resource for id 22 in the ivi_controller.surface_create call is
> > > not created at all, or it is created and then destroyed unwarranted
> > > by the protocol.
> > >
> > > Whenever a protocol message is creating a new object, the message
> > > handler in the compositor cannot ever choose to not create the
> > > wl_resource for it. Likewise, wl_resources cannot be destroyed
> > > without an explicit warrant from protocol exchange, e.g. a destroy
> > > request.
> > >
> > > I'm guessing that you use global identifiers (the argument 80) to
> > > identify surfaces, that "surface 80" does not exist anymore, so you
> > > skip creating the wl_resource. That would be a bug.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190131/3275d121/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ivi-controller.c
Type: application/octet-stream
Size: 50205 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190131/3275d121/attachment-0001.obj>