layout_surface = lyt->get_surface_from_id(id_surface);
if (layout_surface == NULL) {
    return;
}

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@gmail.com> wrote: > On Mon, 31 Dec 2018 20:08:24 +0530 > Ikshwaku Chauhan <ikshwaku.ec2004@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@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. > > > >