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

2019-01-01 Thread Pekka Paalanen 
On Mon, 31 Dec 2018 20:08:24 +0530
Ikshwaku Chauhan  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  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.
> >


pgp0RJ0qSI6qb.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2018-12-31 Thread Ikshwaku Chauhan 
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  wrote:

> On Fri, 28 Dec 2018 15:46:23 +0530
> Ikshwaku Chauhan  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_disp...@1.sync(new id wl_callback@23)
> > [217764.394] wl_display@1.delete_id(23)
> > [217764.456] wl_callb...@23.done(0)
> > [217765.170]  -> wl_disp...@1.sync(new id wl_callback@23)
> > [217765.660] wl_display@1.delete_id(23)
> > [217765.871] wl_callb...@23.done(0)
> > [217765.921]  -> ivi_controller_surface@22.set_source_rectangle(0, 0,
> 800,
> > 480)
> > [217766.272]  -> wl_disp...@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
>
(gdb) bt full
#0  0xb6ae317c in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
_sys_result = 0
pd = 0xb34093f0
pid = 
selftid = 2247
#1  0xb6ae6f24 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {3064713540, 3069797744, 117156, 3007355056, 0, 1, 5, 
3064029184, 117208, 3007355056, 0, 1, 5, 1, 
  3007351444, 3069713004, 3032540112, 1, 5, 0, 0, 3064712164, 0, 
3007351840, 0, 4294967280, 0, 464492, 3066080448, 3069743276, 2997878784, 
131072}}, sa_flags = 0, sa_restorer = 0x1}
sigs = {__val = {32, 0 }}
#2  0xb6a1945c in display_protocol_error (display=0x87ca8, code=0, id=1, 
intf=0xb6a32048 )
at 
/data/work/ichauhan/workspace/MMT2020/yocto/fresh/elina-mmt2020-gclient/elina-distro/build-mmt2020-a880/tmp/work/cortexa15hf-vfp-neon-elina-linux-gnueabi/wayland/1.11.0-r0/wayland-1.11.0/src/wayland-client.c:180
No locals.
#3  0xb6a1a38c in display_handle_error (data=0x87ca8, display=0x87ca8, 
object=0x87ca8, code=0, message=0xb2b018c8 "invalid object 31")
at

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

2018-12-30 Thread Pekka Paalanen 
On Fri, 28 Dec 2018 15:46:23 +0530
Ikshwaku Chauhan  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_disp...@1.sync(new id wl_callback@23)
> [217764.394] wl_display@1.delete_id(23)
> [217764.456] wl_callb...@23.done(0)
> [217765.170]  -> wl_disp...@1.sync(new id wl_callback@23)
> [217765.660] wl_display@1.delete_id(23)
> [217765.871] wl_callb...@23.done(0)
> [217765.921]  -> ivi_controller_surface@22.set_source_rectangle(0, 0, 800,
> 480)
> [217766.272]  -> wl_disp...@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


pgpykEZrr0ghO.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2018-12-28 Thread Ikshwaku Chauhan 
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.

[216074.552] ivi_controller@6.surface(80)
[216074.635]  -> ivi_controller@6.surface_create(80, new id
ivi_controller_surface@23)
[216074.710] ivi_input@7.input_acceptance(80, "default", 1)
[216075.760] ivi_controller_surface@23.opacity(1.00)
[216075.861] ivi_controller_surface@23.source_rectangle(0, 0, 0, 0)
[216075.940] ivi_controller_surface@23.destination_rectangle(0, 0, 1, 1)
[216076.018] ivi_controller_surface@23.orientation(0)
[216076.052] ivi_controller_surface@23.visibility(0)
[216076.085] ivi_controller_surface@23.layer(nil)
[216076.119] ivi_controller_surface@23.configuration(800, 480)
[216120.940] ivi_controller_surface@23.destroyed()
[216121.038]  -> ivi_controller_surface@23.destroy(1)
[216123.417]  -> wl_disp...@1.sync(new id wl_callback@22)
[216124.103] wl_display@1.delete_id(23)
[216124.153] wl_display@1.delete_id(22)
[216124.191] wl_callb...@22.done(0)
[216620.312] ivi_controller@6.surface(80)
[216620.417]  -> ivi_controller@6.surface_create(80, new id
ivi_controller_surface@22)
[216620.520] ivi_input@7.input_acceptance(80, "default", 1)
[216620.770] ivi_controller_surface@22.opacity(1.00)
[216620.817] ivi_controller_surface@22.source_rectangle(0, 0, 0, 0)
[216620.895] ivi_controller_surface@22.destination_rectangle(0, 0, 1, 1)
[216620.971] ivi_controller_surface@22.orientation(0)
[216640.269] ivi_controller_surface@22.visibility(0)
[216640.391] ivi_controller_surface@22.layer(nil)
[216640.430] ivi_controller_surface@22.configuration(800, 480)
[216640.525]  -> wl_disp...@1.sync(new id wl_callback@23)
[216660.432] wl_display@1.delete_id(23)
[216660.593] ivi_controller_surface@22.destroyed()
[216660.658]  -> ivi_controller_surface@22.destroy(1)
[216660.707] wl_callb...@23.done(0)
[216690.474]  -> wl_disp...@1.sync(new id wl_callback@23)
[216692.259] wl_display@1.delete_id(22)
[216692.324] wl_display@1.delete_id(23)
[216692.359] wl_callb...@23.done(0)
[217191.471] ivi_controller@6.surface(80)
[217191.544]  -> ivi_controller@6.surface_create(80, new id
ivi_controller_surface@23)
[217191.609] ivi_input@7.input_acceptance(80, "default", 1)
[217192.321] ivi_controller_surface@23.opacity(1.00)
[217192.380] ivi_controller_surface@23.source_rectangle(0, 0, 0, 0)
[217192.458] ivi_controller_surface@23.destination_rectangle(0, 0, 1, 1)
[217192.532] ivi_controller_surface@23.orientation(0)
[217192.565] ivi_controller_surface@23.visibility(0)
[217192.599] ivi_controller_surface@23.layer(nil)
[217192.632] ivi_controller_surface@23.configuration(800, 480)
[217193.993] ivi_controller_surface@23.source_rectangle(0, 0, 800, 480)
[217194.291] ivi_controller_surface@23.destination_rectangle(0, 0, 800, 480)
[217236.738] ivi_controller_surface@23.destroyed()
[217236.852]  -> ivi_controller_surface@23.destroy(1)
[217237.306]  -> wl_disp...@1.sync(new id wl_callback@22)
[217237.627] wl_display@1.delete_id(23)
[217237.678] wl_display@1.delete_id(22)
[217237.715] wl_callb...@22.done(0)
[217753.952] ivi_controller@6.surface(80)
[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_disp...@1.sync(new id wl_callback@23)
[217764.394] wl_display@1.delete_id(23)
[217764.456] wl_callb...@23.done(0)
[217765.170]  -> wl_disp...@1.sync(new id wl_callback@23)
[217765.660] wl_display@1.delete_id(23)
[217765.871] wl_callb...@23.done(0)
[217765.921]  -> ivi_controller_surface@22.set_source_rectangle(0, 0, 800,
480)
[217766.272]  -> wl_disp...@1.sync(new id wl_callback@23)
[217773.004] wl_display@1.error(wl_display@1, 0, "invalid object 22")
Error communicating with wayland: Invalid argument
[217773.310]  -> wl_disp...@1.sync(new id wl_callback@24)
Error communicating with wayland: Invalid argument
[217773.416]  -> wl_disp...@1.sync(new id wl_callback@25)
Error communicating with wayland: Invalid argument
[218279.632]  -> wl_disp...@1.sync(new id wl_callback@26)
Error communicating with wayland: Invalid argument
[218279.776]  -> wl_disp...@1.sync(new id wl_callback@27)

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.

Thanks in advance.

Regards,
Ikshwaku


On Fri, Dec 28, 2018 at 3:09 PM Pekka Paalanen  wrote:

> On Thu, 27 Dec 2018 11:55:03 -0800
> Dima Ryazanov  wrote:
>
> > Hello,
> >
> > Yes, that's expected. From the documentation
> > <
> https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_display-event-error
> >:
> > "The error event is sent out when a fatal (non-recoverable) error has
> > occurred"
> > It indicates a bug in the code, so there's no point in

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

2018-12-28 Thread Pekka Paalanen 
On Thu, 27 Dec 2018 11:55:03 -0800
Dima Ryazanov  wrote:

> Hello,
> 
> Yes, that's expected. From the documentation
> :
> "The error event is sent out when a fatal (non-recoverable) error has
> occurred"
> It indicates a bug in the code, so there's no point in handling the error.

Correct. After any protocol error, the Wayland connetion is dead.
The only way to recover is to clean up the old connection and make
a new one, starting from scratch.

Of course, runtime recovery is just a band-aid, and you really
should fix the underlying bug that caused the protocol error in the
first place. A protocol error is conceptually not much different
from a segmentation fault or a crash - it should never happen.


Thanks,
pq


> On Thu, Dec 27, 2018 at 6:40 AM Ikshwaku Chauhan 
> wrote:
> 
> > Hello All,
> >
> > We are facing an issue where we are not receiving any surface/layer
> > creation/distortion notifications from Layermanager.
> >
> > We debugged and found that, once we get "*display protocol error :
> > Invalid Object XX" i.e, (wl_display@1.error(wl_display@1, 0, "invalid
> > object XX"))* on wayland client side, there is No further communication
> > between Wayland Protocol and Client to and from both.
> >
> > Is this an expected behavior or any recovery is possible?
> >
> > We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
> > on TI's Soc.
> >
> > Thanks you in advance.
> >
> >
> > Regards,
> >
> > Ikshwaku


pgp5HzvO6M8TS.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2018-12-27 Thread Dima Ryazanov 
Hello,

Yes, that's expected. From the documentation
:
"The error event is sent out when a fatal (non-recoverable) error has
occurred"
It indicates a bug in the code, so there's no point in handling the error.

On Thu, Dec 27, 2018 at 6:40 AM Ikshwaku Chauhan 
wrote:

> Hello All,
>
> We are facing an issue where we are not receiving any surface/layer
> creation/distortion notifications from Layermanager.
>
> We debugged and found that, once we get "*display protocol error :
> Invalid Object XX" i.e, (wl_display@1.error(wl_display@1, 0, "invalid
> object XX"))* on wayland client side, there is No further communication
> between Wayland Protocol and Client to and from both.
>
> Is this an expected behavior or any recovery is possible?
>
> We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
> on TI's Soc.
>
> Thanks you in advance.
>
>
> Regards,
>
> Ikshwaku
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2018-12-27 Thread Ikshwaku Chauhan 
Hello All,

We are facing an issue where we are not receiving any surface/layer
creation/distortion notifications from Layermanager.

We debugged and found that, once we get "*display protocol error : Invalid
Object XX" i.e, (wl_display@1.error(wl_display@1, 0, "invalid object XX"))*
on wayland client side, there is No further communication between Wayland
Protocol and Client to and from both.

Is this an expected behavior or any recovery is possible?

We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
on TI's Soc.

Thanks you in advance.


Regards,

Ikshwaku
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel