<div dir="ltr"><div dir="ltr">Hello Pekka, <div><br></div><div>Thanks for your reply.</div><div>Here we are trying to identify the exact root cause for the protocol error. we deliberately dumped the back trace by calling <b>abort in display_protocol_error</b> function and attaching backtrace for your reference. </div><div>Could you please have a look and provide your inputs.</div><div><br></div><div>We have one more query,</div><div>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.</div><div>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.<br></div><div><br></div><div>Is this the expected behavior for "Protocol error"?  Please provide you inputs for this as well.</div><div><br></div><div>Thanks in advance.</div><div><br></div><div>Regards,</div><div>Ikshwaku</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 30, 2018 at 2:42 PM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 28 Dec 2018 15:46:23 +0530<br>
Ikshwaku Chauhan <<a href="mailto:ikshwaku.ec2004@gmail.com" target="_blank">ikshwaku.ec2004@gmail.com</a>> wrote:<br>
<br>
> Hello Pekka, Hello Dima,<br>
> <br>
> Thanks for your prompt responce.<br>
> After analyzing the below wayland client logs we concluded that we are<br>
> getting the *Protocol Error: Invalid Object*, because we are trying to set<br>
> the property of a destroyed surface.<br>
<br>
...<br>
<br>
> [217759.719]  -> ivi_controller@6.surface_create(80, new id<br>
> ivi_controller_surface@22)<br>
> [217759.822] ivi_input@7.input_acceptance(80, "default", 1)<br>
> [217763.257]  -> wl_display@1.sync(new id wl_callback@23)<br>
> [217764.394] wl_display@1.delete_id(23)<br>
> [217764.456] wl_callback@23.done(0)<br>
> [217765.170]  -> wl_display@1.sync(new id wl_callback@23)<br>
> [217765.660] wl_display@1.delete_id(23)<br>
> [217765.871] wl_callback@23.done(0)<br>
> [217765.921]  -> ivi_controller_surface@22.set_source_rectangle(0, 0, 800,<br>
> 480)<br>
> [217766.272]  -> wl_display@1.sync(new id wl_callback@23)<br>
> [217773.004] wl_display@1.error(wl_display@1, 0, "invalid object 22")<br>
> <br>
> Could you please have a look and share your inputs about our findings.<br>
> Attaching the complete logs.<br>
> <br>
> Here we have a use case, where we are creating and destroying the surfaces<br>
> very quickly.<br>
> One more thing this is an some time issue.<br>
<br>
Well, I do not see why object id 22 would not exist in that log,<br>
it was just created.<br>
<br>
If I had to guess, you have a compositor-side bug. Either the<br>
wl_resource for id 22 in the ivi_controller.surface_create call is<br>
not created at all, or it is created and then destroyed unwarranted<br>
by the protocol.<br>
<br>
Whenever a protocol message is creating a new object, the message<br>
handler in the compositor cannot ever choose to not create the<br>
wl_resource for it. Likewise, wl_resources cannot be destroyed<br>
without an explicit warrant from protocol exchange, e.g. a destroy<br>
request.<br>
<br>
I'm guessing that you use global identifiers (the argument 80) to<br>
identify surfaces, that "surface 80" does not exist anymore, so you<br>
skip creating the wl_resource. That would be a bug.<br>
<br>
If so, this also shows a fundamental flaw in global identifiers<br>
like that: a client can never be sure that the global identifier is<br>
valid. Therefore you must design the ivi_controller_surface<br>
interface to deal with the fact that the global identifier it was<br>
created with was or became invalid, and add an event to tell the<br>
client the ivi_controller_surface is invalid. That event would then<br>
allow the client to destroy the ivi_controller_surface, which would<br>
let the compositor destroy the wl_resource.<br>
<br>
Another corollary to this is that every interface that uses or<br>
refers to a ivi_controller_surface object must be prepared to deal<br>
with one that points to an invalid or non-existent underlying<br>
surface. No amount of Wayland roundtrips will save you from that.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div>