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. 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. Is this the expected behavior for "Protocol error"? Please provide you inputs for this as well. Thanks in advance. Regards, Ikshwaku On Sun, Dec 30, 2018 at 2:42 PM Pekka Paalanen <ppaalanen@gmail.com> wrote: > On Fri, 28 Dec 2018 15:46:23 +0530 > Ikshwaku Chauhan <ikshwaku.ec2004@gmail.com> wrote: > > > Hello Pekka, Hello Dima, > > > > Thanks for your prompt responce. > > After analyzing the below wayland client logs we concluded that we are > > getting the *Protocol Error: Invalid Object*, because we are trying to > set > > the property of a destroyed surface. > > ... > > > [217759.719] -> ivi_controller@6.surface_create(80, new id > > ivi_controller_surface@22) > > [217759.822] ivi_input@7.input_acceptance(80, "default", 1) > > [217763.257] -> wl_display@1.sync(new id wl_callback@23) > > [217764.394] wl_display@1.delete_id(23) > > [217764.456] wl_callback@23.done(0) > > [217765.170] -> wl_display@1.sync(new id wl_callback@23) > > [217765.660] wl_display@1.delete_id(23) > > [217765.871] wl_callback@23.done(0) > > [217765.921] -> ivi_controller_surface@22.set_source_rectangle(0, 0, > 800, > > 480) > > [217766.272] -> wl_display@1.sync(new id wl_callback@23) > > [217773.004] wl_display@1.error(wl_display@1, 0, "invalid object 22") > > > > Could you please have a look and share your inputs about our findings. > > Attaching the complete logs. > > > > Here we have a use case, where we are creating and destroying the > surfaces > > very quickly. > > One more thing this is an some time issue. > > Well, I do not see why object id 22 would not exist in that log, > it was just created. > > 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. > > If so, this also shows a fundamental flaw in global identifiers > like that: a client can never be sure that the global identifier is > valid. Therefore you must design the ivi_controller_surface > interface to deal with the fact that the global identifier it was > created with was or became invalid, and add an event to tell the > client the ivi_controller_surface is invalid. That event would then > allow the client to destroy the ivi_controller_surface, which would > let the compositor destroy the wl_resource. > > Another corollary to this is that every interface that uses or > refers to a ivi_controller_surface object must be prepared to deal > with one that points to an invalid or non-existent underlying > surface. No amount of Wayland roundtrips will save you from that. > > > Thanks, > pq >