Xpra 6.2 crashes on client connect

[janLo]

Describe the bug Since xpra 6.2 the server constantly disconnects a newly connected client due to an internal exception.

It seems that the xdg-menu-handling is somehow broken:

2024-10-14 11:06:29,986 Error in worker thread processing item <bound method MenuProvider.got_menu_data of <xpra.server.menu_provider.MenuProvider object at 0x7f2773524630>>
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/server/background_worker.py", line 74, in run
    item()
  File "/usr/lib/python3/dist-packages/xpra/server/menu_provider.py", line 173, in got_menu_data
    cb(self.menu_data)
  File "/usr/lib/python3/dist-packages/xpra/server/mixins/child_command.py", line 183, in send_updated_menu
    self.do_send_xdg_menu_data(source, xdg_menu)
  File "/usr/lib/python3/dist-packages/xpra/server/mixins/child_command.py", line 178, in do_send_xdg_menu_data
    log(f"{len(xdg_menu)} menu data entries sent to {ss}")
           ^^^^^^^^^^^^^
TypeError: object of type 'NoneType' has no len()
2024-10-14 11:06:29,987 Error: error in network packet write/format
2024-10-14 11:06:29,988  invalid None value in 'setting-change' packet at index 2
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/net/protocol/socket_handler.py", line 497, in write_format_thread_loop
    self._add_packet_to_queue(*gpc())
  File "/usr/lib/python3/dist-packages/xpra/net/protocol/socket_handler.py", line 513, in _add_packet_to_queue
    chunks: tuple[NetPacketType, ...] = tuple(self.encode(packet))
                                              ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/xpra/net/protocol/socket_handler.py", line 671, in encode
    raise TypeError(f"invalid None value in {packet_type!r} packet at index {i}")
TypeError: invalid None value in 'setting-change' packet at index 2

To Reproduce Steps to reproduce the behavior:

1. server command: xpra start :100 --start-child=/bin/true --exit-with-children=no --daemon=no
2. client command: xpra attach 'ssh://<host>/?display=100&ssh=ssh&opengl=no&session-name=workspace'
3. specific action to trigger the bug: that's all.

System Information (please complete the following information):

• Server OS: Debian bookworm (docker container).
• Client OS: Debian bookworm
• Xpra Server Version: 6.2
• Xpra Client Version: 6.2

Additional context Setting the (undocumented?) environment variable XPRA_EXPORT_MENU_DATA to false makes the issue go away.

[janLo]

~The issue also goes away if the package menu-xdg is installed in the system.~

:point_up: This workaround worked once but cannot be reproduced.

[totaam]

A default installation should have installed python-xdg: https://github.com/Xpra-org/xpra/blob/892f117437431fdd64607d93bd321df3c1b51b6f/packaging/debian/xpra/control#L137 https://github.com/Xpra-org/xpra/blob/892f117437431fdd64607d93bd321df3c1b51b6f/packaging/debian/xpra/control#L155-L156 Unfortunately, containers skip the recommended package dependencies.

6de9596660864436c59ff5700dc16b0199a0ba5e should fix this, it is trivial to apply by hand. You can also workaround this issue with --start-new-commands=no.

[EgosOwn]

I just want to note that i also get this exception with 6.2 but neither my server nor my client are running in a container. Both are installed from xpra's repos. Fedora 40 for client and Bookworm for server.

edit: Verified that the 66e69de commit fixes the problem.

[janLo]

Thank you for the fix. I do think, though, that the root cause must be different.

The python3-xdg package was already installed in the containers. Also, we did not see any of this kind of exception before the 6.2 update.

I would also expect to see this in the log file if the package was missing: https://github.com/Xpra-org/xpra/blob/master/xpra/platform/posix/menu_helper.py#L398

[nakkaya]

I am also having the same issue, running in a container with python3-xdg already installed. My latest build fails to connect with the same issue. Is the fix out for ubuntu (jammy) apt repo as well?

[totaam]

@janLo the (unfortunately) very common other way the load_xdg_menu_data method can fail is here: https://github.com/Xpra-org/xpra/blob/6de9596660864436c59ff5700dc16b0199a0ba5e/xpra/platform/posix/menu_helper.py#L457-L465 And should have printed a big warning about broken menus on Debian.

@nakkaya the bug fix has not hit the repos yet, making all the build variants takes many many days. Be patient.

[totaam]

Since many of you seem to be using xpra in containers, what's preventing you from using a distribution less buggy than Debian? So much hassle would be avoided - not just in this ticket.

[EgosOwn]

it is simply what the team i'm on used it for before i came around and it is simplest to stay on approximately the same environment. Ideally we'd move over to Nix or whatever, yes.

[totaam]

Ideally we'd move over to Nix or whatever, yes.

Better choose anything from Tier 1: https://github.com/Xpra-org/xpra/wiki/Platforms (as per this page, Debian and Ubuntu servers are Tier 3)

[totaam]

FYI: I have uploaded 6.2-r2 with this fix for most RPM distros just now, the Debian builds will take a few hours more. (bookworm is already done)

[janLo]

@janLo the (unfortunately) very common other way the load_xdg_menu_data method can fail is here:

https://github.com/Xpra-org/xpra/blob/6de9596660864436c59ff5700dc16b0199a0ba5e/xpra/platform/posix/menu_helper.py#L457-L465

And should have printed a big warning about broken menus on Debian. @nakkaya the bug fix has not hit the repos yet, making all the build variants takes many many days. Be patient.

I did not see this warning either in the logs. Actually no menu related warning was there, only the exception.

[totaam]

@janLo do the 6.2-r2 builds fix the issue for you?

[janLo]

Ideally we'd move over to Nix or whatever, yes.

Better choose anything from Tier 1: https://github.com/Xpra-org/xpra/wiki/Platforms (as per this page, Debian and Ubuntu servers are Tier 3)

What prevents me is years of pain with the RPM ecosystem.

Debian is just the right balance between stable enough and usable.

Nix would be an interesting option but sadly the system is completely broken when it comes to environments where you don't have a internet connection (we have an air-gapped environment with a package mirror for Debian).

[janLo]

@janLo do the 6.2-r2 builds fix the issue for you?

I'll test it as soon as I have a chance (probably tonight or tomorrow)

But the change looked reasonable.

[totaam]

What prevents me is years of pain with the RPM ecosystem.

I hear you. The dnf ongoing pain is not pretty. That said, the deb packaging tools are so kludgy, it's not funny.

Debian is just the right balance between stable enough and usable.

I used to believe that to be true, my deeper DEB packaging experience made me realize that "stable" has a different meaning in Debian-land, one that I fundamentally disagree with.

[nakkaya]

For me its similar, some of the software I rely on only supports Ubuntu.

[janLo]

@totaam 6.2-r2 fixes the problem here.

Regarding the debian-packaging I do agree if it comes to packaging python software. To be honest, I package python tooling lately only via dh_virtualenv ;)

But from a user's perspective, it's just the most works-for-me distribution. I'm using it on fleets of servers and all my managed end-user systems since 2006 and never felt the urge to look back to RPM-based distros ;)