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é <phi...@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)".
