virt-manager failing on macOS M1 Monterey after most recent update

[jorgy80236]

brew gist-logs <formula> link OR brew config AND brew doctor output

$ brew doctor
Your system is ready to brew.

$ brew config
HOMEBREW_VERSION: 3.6.9
ORIGIN: https://github.com/Homebrew/brew
HEAD: 92e3ea0ecc219510d850c639c035bf0cdc6903f3
Last commit: 35 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 47c924656ffea421487417ecd363bd60a98900f8
Core tap last commit: 2 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.oPqqpxjRC1/org.xquartz:0
HOMEBREW_EDITOR: /usr/bin/vim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 10
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: 10-core 64-bit arm_firestorm_icestorm
Clang: 14.0.0 build 1400
Git: 2.37.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.79.1 => /usr/bin/curl
macOS: 12.6.1-arm64
CLT: 14.1.0.0.1.1666437224
Xcode: 14.1
Rosetta 2: false

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro18,3
  Chip: Apple M1 Pro
  Total Number of Cores:    10 (8 performance and 2 efficiency)
  Memory:   16 GB
  System Firmware Version:  8419.41.10
  OS Loader Version:    7459.141.1

Verification

• [X] I ran brew update and am still able to reproduce my issue.
• [X] I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?

A couple of days ago, I did a brew upgrade and now virt-manager is failing when I connect to the console of remote KVM machines.

What happened (include all command output)?

This is a fully patched Monterey Apple Silicon box running an up-to-date brew. When I start virt-manager, I get a new warning, but it seems to start okay.

$ virt-manager 
/opt/homebrew/Cellar/virt-manager/4.1.0_3/libexec/lib/python3.10/site-packages/requests/__init__.py:109: RequestsDependencyWarning: urllib3 (1.26.12) or chardet (None)/charset_normalizer (3.0.0) doesn't match a supported version!
  warnings.warn(

However, when I try to pull up a guest on a remote host, it crashes trying to access the console. No error message on console is given. Here is the output from the macOS crash dialog:

https://gist.github.com/jorgy80236/08c37d8b4d4e9aa910dc9cdc6c44d557

It doesn't happen on every host I've tested, but reliably crashes on the ones that don't work.

Fedora Core 34 libvirt-7.0.0-8.fc34.x86_64 Crash: no

Rocky 8.6 libvirt-8.0.0-5.4.module+el8.6.0+1000+18e3b59f.x86_64 Crash: yes - used to work

Rocky 8.6 libvirt-8.0.0-5.5.module+el8.6.0+1052+ff61d164.x86_64 Crash: yes - used to work, and several servers on this rev all crash

It used to work everywhere, and it looks like there is something that has been introduced in the most recent virt-viewer brew update that doesn't like the version 8.0.0 of libvirt on the server. I will be pleased to furnish any more information required. Thanks,

jorgy

What did you expect to happen?

After starting brew-manager, and opening up a remote console, in the past I was able to interact with the console of the KVM guest. However now, the python app crashes and I'm presented with a macOS stack track (attached above).

Step-by-step reproduction instructions (by running brew commands)

doop:~ jorgy$ brew update
Already up-to-date.
doop:~ jorgy$ virt-manager 
/opt/homebrew/Cellar/virt-manager/4.1.0_3/libexec/lib/python3.10/site-packages/requests/__init__.py:109: RequestsDependencyWarning: urllib3 (1.26.12) or chardet (None)/charset_normalizer (3.0.0) doesn't match a supported version!
  warnings.warn(

[ after connecting to remote console, app crashes here and I'm presented with the macOS dialog with stack trace ]

[SMillerDev]

Have you tried to debug this with upstream yet?

[SMillerDev]

Looking at the history of the formula the resources in it were updated a couple of times, it could be that one of the component updates broke your usage.

[jorgy80236]

I don't have a way to test on the consoles of the KVM servers, as they are headless. However, running virt-manager on the servers and tunneling X11 through ssh to my mac, works on all servers. Are there other ways you'd like me to test?

[SMillerDev]

I meant with the upstream developers. I guess with this particular tool that term can get confusing.

[AsherVo]

+1 this is also happening on my intel mac running Monterey.

[peterupton]

+1 I can also confirm I see the same issue on my mac running Ventura 13.0.1.

[Bo98]

Hmm this is tricky to track down given I don't have the means to test this.

This sounds like https://gitlab.gnome.org/GNOME/gtk-vnc/-/issues/17, but that issue was reported over a year ago and gtk-vnc has not been touched in as long. So if it is a new issue, then there must be something else that's triggering it.

But with that said I'm happy to apply the --with-coroutine=gthread change to gtk-vnc if anyone can confirm it works. ucontext does seem to have been deprecated on macOS for a while now.

[marvinmarnold]

+1 on Monterey 12.6.1 w/ Intel

[SMillerDev]

Please stop posting +1, it only hides debugging information. Instead write an issue for the developers of virt-manager and get them to help.

[tinsjourney]

@Bo98 I confirm it's working using the --with-coroutine=gthread on macOS: 12.6.2-x86_64

I edited the gtk-vnc.rb and change the install function :

  def install
    mkdir "build" do
      # This is workaround. MacOS has deprecate coroutine ucontext.
      # It needs to be fixed in gtk-vnc - use gthread coroutines.
      on_macos do
        system "meson", *std_meson_args, "-Dwith-coroutine=gthread", ".."
      end
      on_linux do
      system "meson", *std_meson_args, "-Dwith-vala=disabled", ".."
      end
      system "ninja", "-v"
      system "ninja", "install", "-v"
    end
  end

[jorgy80236]

I'm relatively new to brew (former ports user). I haven't seen this update show up in my installation yet. I looked around for the gtk-vnc-rb and found two:

./Library/Taps/homebrew/homebrew-core/Formula/gtk-vnc.rb
./Cellar/gtk-vnc/1.3.1/.brew/gtk-vnc.rb

How do I make the change locally? Thank you.

[SMillerDev]

You can do brew edit formula

[berrange]

As upstream maintainer of gtk-vnc, I can confirm the ucontext coroutine backend is completely broken. the macOS aarch64 impl of getcontext writes outside the bounds of the struct ucontext_t pointer it is given, smashing data in other GTK-VNC structs.

Please build with -Dwith-coroutine=gthread on macOS aarch64 platforms.

I would also recommend running ninja test as part of the formula, as that would have identified that the current build was broken from the start on M1.

[SMillerDev]

Could you make that coroutine setting the default in your project? That would make sure everyone uses the correct setting and not just Homebrew.

[berrange]

Upstream, I'm aiming to try to make a sigaltstack based coroutine impl, since the gthread impl is quite high overhead. Either way the next release of gtk-vnc will do the right thing automatically. I don't have an ETA for the next release, so meanwhile homebrew needs to add that build flag for gthread to avoid being completely broken on M1.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[carlocab]

This should be fixed now. You may need to do

brew update && brew reinstall gtk-vnc

to pick up the fix.

Please open a new issue if the above command does not fix it for you.