tests/qtest: Is vnc-display-test supposed to work on Darwin?

tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Philippe Mathieu-Daudé]

Hi,

The vnc-display-test is failing on Darwin:

tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error: 
Unsupported auth type 17973672

Is it supposed to pass, or should we skip it similarly to Windows?

Thanks,

Phil.

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Marc-André Lureau]

Hi

On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> Hi,
>
> The vnc-display-test is failing on Darwin:
>
> tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
> Unsupported auth type 17973672

It is supposed to pass. Can you share more details? It doesn't look
like an endianness issue, at first sight..

> Is it supposed to pass, or should we skip it similarly to Windows?

(I hope it'll cover Windows soon)

-- 
Marc-André Lureau

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Philippe Mathieu-Daudé]

On 5/12/22 08:51, Marc-André Lureau wrote:
> On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>
>> The vnc-display-test is failing on Darwin:
>>
>> tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
>> Unsupported auth type 17973672
> 
> It is supposed to pass. Can you share more details? It doesn't look
> like an endianness issue, at first sight..

Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:

# Start of vnc-display tests
vnc_server_dpy_recreate VNC server dpy recreate dpy=0x130008000 
size=640x480 fmt=537004168
Initializing VNC server with no auth
vnc_auth_init VNC auth init state=0x130008000 websock=0 auth=1 subauth=0
Initializing VNC server with no auth
vnc_auth_init VNC auth init state=0x130008000 websock=1 auth=1 subauth=0
vnc_client_connect VNC client connect state=0x130050000 ioc=0x13f7077f0
Client sioc=0x13f7077f0 ws=0 auth=1 subauth=0
New client on socket 0x13f7077f0
vnc_set_share_mode/0x13f7077f0: undefined -> connecting
Write Plain: Pending output 0x14880a400 size 4096 offset 12. Wait SSF 0
Wrote wire 0x14880a400 12 -> 12
Read plain 0x0 size 0 offset 0
Read wire 0x13f8c8c00 4096 -> 12
Client request protocol version 3.8
Write Plain: Pending output 0x14880a400 size 4096 offset 2. Wait SSF 0
Wrote wire 0x14880a400 2 -> 2
Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072
Read plain 0x13f8c8c00 size 4096 offset 0
Read wire 0x13f8c8c00 4096 -> 1
vnc_auth_reject VNC client auth rejected state=0x130050000 method 
expected=1 got=176
Write Plain: Pending output 0x14880a400 size 4096 offset 30. Wait SSF 0
Wrote wire 0x14880a400 30 -> 30
Closing down client sock: protocol error
vnc_client_disconnect_start VNC client disconnect start 
state=0x130050000 ioc=0x13f7077f0
vnc_set_share_mode/0x13f7077f0: connecting -> disconnected
vnc_client_disconnect_finish VNC client disconnect finish 
state=0x130050000 ioc=0x13f7077f0

** (tests/qtest/vnc-display-test:8465): ERROR **: 11:59:18.613: 
vnc-error: Unsupported auth type 5489072
Trace/BPT trap: 5

Does that help? What else can I do to gather more info?

>> Is it supposed to pass, or should we skip it similarly to Windows?
> 
> (I hope it'll cover Windows soon)
> 

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Daniel P. Berrangé]

On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
> On 5/12/22 08:51, Marc-André Lureau wrote:
> > On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > > 
> > > The vnc-display-test is failing on Darwin:
> > > 
> > > tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
> > > Unsupported auth type 17973672
> > 
> > It is supposed to pass. Can you share more details? It doesn't look
> > like an endianness issue, at first sight..
> 
> Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:
> 
> # Start of vnc-display tests
> vnc_server_dpy_recreate VNC server dpy recreate dpy=0x130008000 size=640x480
> fmt=537004168
> Initializing VNC server with no auth
> vnc_auth_init VNC auth init state=0x130008000 websock=0 auth=1 subauth=0
> Initializing VNC server with no auth
> vnc_auth_init VNC auth init state=0x130008000 websock=1 auth=1 subauth=0
> vnc_client_connect VNC client connect state=0x130050000 ioc=0x13f7077f0
> Client sioc=0x13f7077f0 ws=0 auth=1 subauth=0
> New client on socket 0x13f7077f0
> vnc_set_share_mode/0x13f7077f0: undefined -> connecting
> Write Plain: Pending output 0x14880a400 size 4096 offset 12. Wait SSF 0
> Wrote wire 0x14880a400 12 -> 12
> Read plain 0x0 size 0 offset 0
> Read wire 0x13f8c8c00 4096 -> 12
> Client request protocol version 3.8
> Write Plain: Pending output 0x14880a400 size 4096 offset 2. Wait SSF 0
> Wrote wire 0x14880a400 2 -> 2
> Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072

^^^^ This specific message is comnig from the gtk-vnc client rather
than QEMU

Still doesn't tell us if the flaw is server or client side. The
logs from QEMU are insufficient. In theory it should be reporting
auth type == 0 though, for 'no auth' configs. 

> Read plain 0x13f8c8c00 size 4096 offset 0
> Read wire 0x13f8c8c00 4096 -> 1
> vnc_auth_reject VNC client auth rejected state=0x130050000 method expected=1
> got=176
> Write Plain: Pending output 0x14880a400 size 4096 offset 30. Wait SSF 0
> Wrote wire 0x14880a400 30 -> 30
> Closing down client sock: protocol error
> vnc_client_disconnect_start VNC client disconnect start state=0x130050000
> ioc=0x13f7077f0
> vnc_set_share_mode/0x13f7077f0: connecting -> disconnected
> vnc_client_disconnect_finish VNC client disconnect finish state=0x130050000
> ioc=0x13f7077f0
> 
> ** (tests/qtest/vnc-display-test:8465): ERROR **: 11:59:18.613: vnc-error:
> Unsupported auth type 5489072
> Trace/BPT trap: 5
> 
> Does that help? What else can I do to gather more info?

Modify vnc-display-test.c to call  vnc_util_set_debug(TRUE);
before vnc_connection_new(), to get the gtk-vnc debug logs
to stderr too.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Philippe Mathieu-Daudé]

On 19/1/23 12:16, Daniel P. Berrangé wrote:
> On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
>> On 5/12/22 08:51, Marc-André Lureau wrote:
>>> On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>>>
>>>> The vnc-display-test is failing on Darwin:
>>>>
>>>> tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
>>>> Unsupported auth type 17973672
>>>
>>> It is supposed to pass. Can you share more details? It doesn't look
>>> like an endianness issue, at first sight..
>>
>> Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:

>> Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072
> 
> ^^^^ This specific message is comnig from the gtk-vnc client rather
> than QEMU
> 
> Still doesn't tell us if the flaw is server or client side. The
> logs from QEMU are insufficient. In theory it should be reporting
> auth type == 0 though, for 'no auth' configs.

>> Does that help? What else can I do to gather more info?
> 
> Modify vnc-display-test.c to call  vnc_util_set_debug(TRUE);
> before vnc_connection_new(), to get the gtk-vnc debug logs
> to stderr too.
Here you go:

vnc_server_dpy_recreate VNC server dpy recreate dpy=0x1588b8000 
size=640x384 fmt=537004168
vnc_auth_init VNC auth init state=0x1588b8000 websock=0 auth=1 subauth=0
vnc_auth_init VNC auth init state=0x1588b8000 websock=1 auth=1 subauth=0
vnc_client_connect VNC client connect state=0x1484b0000 ioc=0x152e667f0
# gtk-vnc-DEBUG: ../src/vncconnection.c Init VncConnection=0x14f0168b0
gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Init 
VncConnection=0x14f0168b0
# gtk-vnc-DEBUG: ../src/vncconnection.c Thinking about auth type 1
gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Thinking about auth 
type 1
# gtk-vnc-DEBUG: ../src/vncconnection.c Decided on auth type 1
gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Decided on auth type 1
# gtk-vnc-DEBUG: ../src/vncconnection.c Open fd=4
gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open fd=4
# gtk-vnc-DEBUG: ../src/vncconnection.c Open coroutine starting
gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open coroutine starting
# gtk-vnc-DEBUG: ../src/vncconnection.c Started background coroutine
gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Started background 
coroutine
# gtk-vnc-DEBUG: ../src/vncconnection.c Connecting to FD 4
gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Connecting to FD 4
# gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 16
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Emit main context 16
# gtk-vnc-DEBUG: ../src/vncconnection.c Protocol initialization
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Protocol initialization
# gtk-vnc-DEBUG: ../src/vncconnection.c Schedule greeting timeout 
0x14f0155e0
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Schedule greeting 
timeout 0x14f0155e0
# gtk-vnc-DEBUG: ../src/vncconnection.c Remove timeout 0x14f0155e0
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Remove timeout 
0x14f0155e0
# gtk-vnc-DEBUG: ../src/vncconnection.c Server version: 3.8
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Server version: 3.8
# gtk-vnc-DEBUG: ../src/vncconnection.c Sending full greeting
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Sending full greeting
# gtk-vnc-DEBUG: ../src/vncconnection.c Using version: 3.8
gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Using version: 3.8
# gtk-vnc-DEBUG: ../src/vncconnection.c Possible auth 1
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Possible auth 1
# gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 14
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 14
# gtk-vnc-DEBUG: ../src/vncconnection.c Waiting for auth type
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Waiting for auth type
# gtk-vnc-DEBUG: ../src/vncconnection.c Choose auth 10486192
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Choose auth 10486192
# gtk-vnc-DEBUG: ../src/vncconnection.c Checking if credentials are needed
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Checking if 
credentials are needed
# gtk-vnc-DEBUG: ../src/vncconnection.c No credentials required
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c No credentials required
# gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 12
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 12
# gtk-vnc-DEBUG: ../src/vncconnection.c Error: Unsupported auth type 
10486192
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Error: Unsupported 
auth type 10486192
# gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 19
gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 19
Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 10486192

** ERROR **: 12:20:30.589: vnc-error: Unsupported auth type 10486192
vnc_auth_reject VNC client auth rejected state=0x1484b0000 method 
expected=1 got=176
vnc_client_disconnect_start VNC client disconnect start 
state=0x1484b0000 ioc=0x152e667f0
vnc_client_disconnect_finish VNC client disconnect finish 
state=0x1484b0000 ioc=0x152e667f0
Trace/BPT trap: 5

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Philippe Mathieu-Daudé]

On 19/1/23 12:16, Daniel P. Berrangé wrote:
> On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
>> On 5/12/22 08:51, Marc-André Lureau wrote:
>>> On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>>>
>>>> The vnc-display-test is failing on Darwin:
>>>>
>>>> tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
>>>> Unsupported auth type 17973672
>>>
>>> It is supposed to pass. Can you share more details? It doesn't look
>>> like an endianness issue, at first sight..

>> ** (tests/qtest/vnc-display-test:8465): ERROR **: 11:59:18.613: vnc-error:
>> Unsupported auth type 5489072
>> Trace/BPT trap: 5
>>
>> Does that help? What else can I do to gather more info?
> 
> Modify vnc-display-test.c to call  vnc_util_set_debug(TRUE);
> before vnc_connection_new(), to get the gtk-vnc debug logs
> to stderr too.

I just realized this is what setting GTK_VNC_DEBUG in env does.

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Daniel P. Berrangé]

On Thu, Jan 19, 2023 at 12:21:58PM +0100, Philippe Mathieu-Daudé wrote:
> On 19/1/23 12:16, Daniel P. Berrangé wrote:
> > On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
> > > On 5/12/22 08:51, Marc-André Lureau wrote:
> > > > On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > > > > 
> > > > > The vnc-display-test is failing on Darwin:
> > > > > 
> > > > > tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
> > > > > Unsupported auth type 17973672
> > > > 
> > > > It is supposed to pass. Can you share more details? It doesn't look
> > > > like an endianness issue, at first sight..
> > > 
> > > Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:
> 
> > > Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072
> > 
> > ^^^^ This specific message is comnig from the gtk-vnc client rather
> > than QEMU
> > 
> > Still doesn't tell us if the flaw is server or client side. The
> > logs from QEMU are insufficient. In theory it should be reporting
> > auth type == 0 though, for 'no auth' configs.
> 
> > > Does that help? What else can I do to gather more info?
> > 
> > Modify vnc-display-test.c to call  vnc_util_set_debug(TRUE);
> > before vnc_connection_new(), to get the gtk-vnc debug logs
> > to stderr too.
> Here you go:
> 
> vnc_server_dpy_recreate VNC server dpy recreate dpy=0x1588b8000 size=640x384
> fmt=537004168
> vnc_auth_init VNC auth init state=0x1588b8000 websock=0 auth=1 subauth=0
> vnc_auth_init VNC auth init state=0x1588b8000 websock=1 auth=1 subauth=0
> vnc_client_connect VNC client connect state=0x1484b0000 ioc=0x152e667f0
> # gtk-vnc-DEBUG: ../src/vncconnection.c Init VncConnection=0x14f0168b0
> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Init
> VncConnection=0x14f0168b0
> # gtk-vnc-DEBUG: ../src/vncconnection.c Thinking about auth type 1
> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Thinking about auth type
> 1
> # gtk-vnc-DEBUG: ../src/vncconnection.c Decided on auth type 1
> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Decided on auth type 1

So here we set conn->auth_type == 1


> # gtk-vnc-DEBUG: ../src/vncconnection.c Open fd=4
> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open fd=4
> # gtk-vnc-DEBUG: ../src/vncconnection.c Open coroutine starting
> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open coroutine starting
> # gtk-vnc-DEBUG: ../src/vncconnection.c Started background coroutine
> gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Started background
> coroutine
> # gtk-vnc-DEBUG: ../src/vncconnection.c Connecting to FD 4
> gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Connecting to FD 4
> # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 16
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Emit main context 16
> # gtk-vnc-DEBUG: ../src/vncconnection.c Protocol initialization
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Protocol initialization
> # gtk-vnc-DEBUG: ../src/vncconnection.c Schedule greeting timeout
> 0x14f0155e0
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Schedule greeting
> timeout 0x14f0155e0
> # gtk-vnc-DEBUG: ../src/vncconnection.c Remove timeout 0x14f0155e0
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Remove timeout
> 0x14f0155e0
> # gtk-vnc-DEBUG: ../src/vncconnection.c Server version: 3.8
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Server version: 3.8
> # gtk-vnc-DEBUG: ../src/vncconnection.c Sending full greeting
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Sending full greeting
> # gtk-vnc-DEBUG: ../src/vncconnection.c Using version: 3.8
> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Using version: 3.8
> # gtk-vnc-DEBUG: ../src/vncconnection.c Possible auth 1
> gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Possible auth 1
> # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 14
> gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 14
> # gtk-vnc-DEBUG: ../src/vncconnection.c Waiting for auth type
> gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Waiting for auth type
> # gtk-vnc-DEBUG: ../src/vncconnection.c Choose auth 10486192

Here we've read conn->auth_type and got back 10486192 nonsense instead
of 1.

Interestingly this value is differetn from the previous debug log
which reported  5489072, so i guess we're getting garbage here for
unknown reasons.

This looks like a gtk-vnc problem rather than QEMU.

I'm a little worried that perhaps the gtk-vnc ucontext coroutine backend
is broken on macOS

What coroutine backend does QEMU end up using on macOS ? Is it the
sigaltstack one ?


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Philippe Mathieu-Daudé]

On 19/1/23 12:33, Daniel P. Berrangé wrote:
> On Thu, Jan 19, 2023 at 12:21:58PM +0100, Philippe Mathieu-Daudé wrote:
>> On 19/1/23 12:16, Daniel P. Berrangé wrote:
>>> On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
>>>> On 5/12/22 08:51, Marc-André Lureau wrote:
>>>>> On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>>>>>
>>>>>> The vnc-display-test is failing on Darwin:
>>>>>>
>>>>>> tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
>>>>>> Unsupported auth type 17973672
>>>>>
>>>>> It is supposed to pass. Can you share more details? It doesn't look
>>>>> like an endianness issue, at first sight..
>>>>
>>>> Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:
>>
>>>> Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072
>>>
>>> ^^^^ This specific message is comnig from the gtk-vnc client rather
>>> than QEMU
>>>
>>> Still doesn't tell us if the flaw is server or client side. The
>>> logs from QEMU are insufficient. In theory it should be reporting
>>> auth type == 0 though, for 'no auth' configs.
>>
>>>> Does that help? What else can I do to gather more info?
>>>
>>> Modify vnc-display-test.c to call  vnc_util_set_debug(TRUE);
>>> before vnc_connection_new(), to get the gtk-vnc debug logs
>>> to stderr too.
>> Here you go:
>>
>> vnc_server_dpy_recreate VNC server dpy recreate dpy=0x1588b8000 size=640x384
>> fmt=537004168
>> vnc_auth_init VNC auth init state=0x1588b8000 websock=0 auth=1 subauth=0
>> vnc_auth_init VNC auth init state=0x1588b8000 websock=1 auth=1 subauth=0
>> vnc_client_connect VNC client connect state=0x1484b0000 ioc=0x152e667f0
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Init VncConnection=0x14f0168b0
>> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Init
>> VncConnection=0x14f0168b0
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Thinking about auth type 1
>> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Thinking about auth type
>> 1
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Decided on auth type 1
>> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Decided on auth type 1
> 
> So here we set conn->auth_type == 1
> 
> 
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Open fd=4
>> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open fd=4
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Open coroutine starting
>> gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open coroutine starting
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Started background coroutine
>> gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Started background
>> coroutine
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Connecting to FD 4
>> gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Connecting to FD 4
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 16
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Emit main context 16
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Protocol initialization
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Protocol initialization
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Schedule greeting timeout
>> 0x14f0155e0
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Schedule greeting
>> timeout 0x14f0155e0
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Remove timeout 0x14f0155e0
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Remove timeout
>> 0x14f0155e0
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Server version: 3.8
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Server version: 3.8
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Sending full greeting
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Sending full greeting
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Using version: 3.8
>> gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Using version: 3.8
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Possible auth 1
>> gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Possible auth 1
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 14
>> gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 14
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Waiting for auth type
>> gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Waiting for auth type
>> # gtk-vnc-DEBUG: ../src/vncconnection.c Choose auth 10486192
> 
> Here we've read conn->auth_type and got back 10486192 nonsense instead
> of 1.
> 
> Interestingly this value is differetn from the previous debug log
> which reported  5489072, so i guess we're getting garbage here for
> unknown reasons.
> 
> This looks like a gtk-vnc problem rather than QEMU.
> 
> I'm a little worried that perhaps the gtk-vnc ucontext coroutine backend
> is broken on macOS
> 
> What coroutine backend does QEMU end up using on macOS ? Is it the
> sigaltstack one ?

   Block layer support
     coroutine backend            : sigaltstack
     coroutine pool               : YES

When trying the coroutine options, with --with-coroutine=windows:

ERROR: 'windows' coroutine backend only valid for Windows

:) and with --with-coroutine=ucontext I get:

ERROR: 'ucontext' backend requested but makecontext not available

config.log hints:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ucontext.h:51:2: 
error: The deprecated ucontext routines require _XOPEN_SOURCE to be defined
#error The deprecated ucontext routines require _XOPEN_SOURCE to be defined
  ^

Adding _XOPEN_SOURCE to QEMU_CFLAGS:

warning: 'makecontext' is deprecated: first deprecated in macOS 10.6 - 
No longer supported [-Wdeprecated-declarations]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ucontext.h:41:6: 
note: 'makecontext' has been explicitly marked deprecated here
void makecontext(ucontext_t *, void (*)(), int, ...);
      ^

So to detect makecontext() I have to add
--extra-cflags=-mmacosx-version-min=10.5 but then linking fails with
multiple "$LIBNAME was built for newer macOS version (13.0) than being
linked (11.0)".

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Daniel P. Berrangé]

On Thu, Jan 19, 2023 at 12:49:48PM +0100, Philippe Mathieu-Daudé wrote:
> On 19/1/23 12:33, Daniel P. Berrangé wrote:
> > On Thu, Jan 19, 2023 at 12:21:58PM +0100, Philippe Mathieu-Daudé wrote:
> > > On 19/1/23 12:16, Daniel P. Berrangé wrote:
> > > > On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
> > > > > On 5/12/22 08:51, Marc-André Lureau wrote:
> > > > > > On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > > > > > > 
> > > > > > > The vnc-display-test is failing on Darwin:
> > > > > > > 
> > > > > > > tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
> > > > > > > Unsupported auth type 17973672
> > > > > > 
> > > > > > It is supposed to pass. Can you share more details? It doesn't look
> > > > > > like an endianness issue, at first sight..
> > > > > 
> > > > > Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:
> > > 
> > > > > Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072
> > > > 
> > > > ^^^^ This specific message is comnig from the gtk-vnc client rather
> > > > than QEMU
> > > > 
> > > > Still doesn't tell us if the flaw is server or client side. The
> > > > logs from QEMU are insufficient. In theory it should be reporting
> > > > auth type == 0 though, for 'no auth' configs.
> > > 
> > > > > Does that help? What else can I do to gather more info?
> > > > 
> > > > Modify vnc-display-test.c to call  vnc_util_set_debug(TRUE);
> > > > before vnc_connection_new(), to get the gtk-vnc debug logs
> > > > to stderr too.
> > > Here you go:
> > > 
> > > vnc_server_dpy_recreate VNC server dpy recreate dpy=0x1588b8000 size=640x384
> > > fmt=537004168
> > > vnc_auth_init VNC auth init state=0x1588b8000 websock=0 auth=1 subauth=0
> > > vnc_auth_init VNC auth init state=0x1588b8000 websock=1 auth=1 subauth=0
> > > vnc_client_connect VNC client connect state=0x1484b0000 ioc=0x152e667f0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Init VncConnection=0x14f0168b0
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Init
> > > VncConnection=0x14f0168b0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Thinking about auth type 1
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Thinking about auth type
> > > 1
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Decided on auth type 1
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Decided on auth type 1
> > 
> > So here we set conn->auth_type == 1
> > 
> > 
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Open fd=4
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open fd=4
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Open coroutine starting
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open coroutine starting
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Started background coroutine
> > > gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Started background
> > > coroutine
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Connecting to FD 4
> > > gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Connecting to FD 4
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 16
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Emit main context 16
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Protocol initialization
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Protocol initialization
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Schedule greeting timeout
> > > 0x14f0155e0
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Schedule greeting
> > > timeout 0x14f0155e0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Remove timeout 0x14f0155e0
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Remove timeout
> > > 0x14f0155e0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Server version: 3.8
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Server version: 3.8
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Sending full greeting
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Sending full greeting
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Using version: 3.8
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Using version: 3.8
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Possible auth 1
> > > gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Possible auth 1
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 14
> > > gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 14
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Waiting for auth type
> > > gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Waiting for auth type
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Choose auth 10486192
> > 
> > Here we've read conn->auth_type and got back 10486192 nonsense instead
> > of 1.
> > 
> > Interestingly this value is differetn from the previous debug log
> > which reported  5489072, so i guess we're getting garbage here for
> > unknown reasons.
> > 
> > This looks like a gtk-vnc problem rather than QEMU.
> > 
> > I'm a little worried that perhaps the gtk-vnc ucontext coroutine backend
> > is broken on macOS
> > 
> > What coroutine backend does QEMU end up using on macOS ? Is it the
> > sigaltstack one ?
> 
>   Block layer support
>     coroutine backend            : sigaltstack
>     coroutine pool               : YES
> 
> When trying the coroutine options, with --with-coroutine=windows:
> 
> ERROR: 'windows' coroutine backend only valid for Windows
> 
> :) and with --with-coroutine=ucontext I get:
> 
> ERROR: 'ucontext' backend requested but makecontext not available
> 
> config.log hints:
> 
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ucontext.h:51:2:
> error: The deprecated ucontext routines require _XOPEN_SOURCE to be defined
> #error The deprecated ucontext routines require _XOPEN_SOURCE to be defined
>  ^
> 
> Adding _XOPEN_SOURCE to QEMU_CFLAGS:
> 
> warning: 'makecontext' is deprecated: first deprecated in macOS 10.6 - No
> longer supported [-Wdeprecated-declarations]
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ucontext.h:41:6:
> note: 'makecontext' has been explicitly marked deprecated here
> void makecontext(ucontext_t *, void (*)(), int, ...);
>      ^
> 
> So to detect makecontext() I have to add
> --extra-cflags=-mmacosx-version-min=10.5 but then linking fails with
> multiple "$LIBNAME was built for newer macOS version (13.0) than being
> linked (11.0)".

Yes, ucontext has been deprecated forever on macOS, but in practice it
has still been functional if you define _XOPEN_SOURCE, which is what
gtk-vnc has done traditionally.

I presume this is on the aarch64 macOS though, and so all bets are off
wrt ucontext backend unless someone knows it works correctly with the
m1 port. I fear that's not the case though, given the wierd error
scenario we're hitting in gtk-vnc.

I might need to add a sigaltstack impl to gtk-vnc

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?

[Daniel P. Berrangé]

On Thu, Jan 19, 2023 at 12:00:41PM +0000, Daniel P. Berrangé wrote:
> On Thu, Jan 19, 2023 at 12:49:48PM +0100, Philippe Mathieu-Daudé wrote:
> > So to detect makecontext() I have to add
> > --extra-cflags=-mmacosx-version-min=10.5 but then linking fails with
> > multiple "$LIBNAME was built for newer macOS version (13.0) than being
> > linked (11.0)".
> 
> Yes, ucontext has been deprecated forever on macOS, but in practice it
> has still been functional if you define _XOPEN_SOURCE, which is what
> gtk-vnc has done traditionally.
> 
> I presume this is on the aarch64 macOS though, and so all bets are off
> wrt ucontext backend unless someone knows it works correctly with the
> m1 port. I fear that's not the case though, given the wierd error
> scenario we're hitting in gtk-vnc.

Yep,  I've confirmed there's something broken with gtk-vnc. When we
call 'getcontext' is corrupts memory in gtk-vnc structs. This makes
me believe that the defined 'struct ucontext_t' is too small for use
with 'getcontext' on macOS aarch64 platforms.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|