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
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.
On Sun, Dec 30, 2018 at 2:42 PM Pekka Paalanen firstname.lastname@example.org wrote:
On Fri, 28 Dec 2018 15:46:23 +0530
Ikshwaku Chauhan email@example.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
the property of a destroyed surface.
[217759.719] -> firstname.lastname@example.org_create(80, new id
[217759.822] email@example.com_acceptance(80, "default", 1)
[217763.257] -> firstname.lastname@example.org(new id wl_callback@23)
[217765.170] -> email@example.com(new id wl_callback@23)
[217765.921] -> firstname.lastname@example.org_source_rectangle(0, 0,
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
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
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.