Crash on resume when monitor setup changed

[titilambert]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

sway

WezTerm version

20220720-074534-41ee60c9

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Wezterm crashes on resume (after suspend) when an external monitor is plugged or unplugged during the suspend

not a valid new object id (4278190080), message data_offer(n)
15:53:49.353  ERROR  wezterm_gui > running message loop: error during event_q.read_events protocol_error=None: Invalid argument (os error 22); terminating

To Reproduce

1. Launch wezterm
2. suspend the laptop
3. plug a new monitor
4. resume
5. it crashes

Configuration

local wezterm = require 'wezterm';
local act = wezterm.action

return {
  tab_bar_at_bottom = true,
  window_close_confirmation = "AlwaysPrompt",
  skip_close_confirmation_for_processes_named = {},
  harfbuzz_features = {"calt=0", "clig=0", "liga=0"},
   window_padding = {
    left = 1,
    right = 1,
    top = 1,
    bottom = 1,
  },
  -- font = wezterm.font("DejaVu Sans Mono"),
  font = wezterm.font("Noto Mono"),
  keys = {
    {key="LeftArrow", mods="SHIFT", action=act.ActivateTabRelative(-1)},
    {key="RightArrow", mods="SHIFT", action=act.ActivateTabRelative(1)},
    {key="LeftArrow", mods="SHIFT|CTRL", action=act.MoveTabRelative(-1)},
    {key="RightArrow", mods="SHIFT|CTRL", action=act.MoveTabRelative(1)},
    -- {key="w", mods="SHIFT|CTRL", action=wezterm.action.CloseCurrentTab{confirm=true}},
    -- {key="w", mods="SHIFT|CTRL", action=wezterm.action.CloseCurrentPane{confirm=true}},
  }
}

Expected Behavior

No response

Logs

not a valid new object id (4278190080), message data_offer(n)
15:53:49.353  ERROR  wezterm_gui > running message loop: error during event_q.read_events protocol_error=None: Invalid argument (os error 22); terminating

Anything else?

No response

[wez]

Possible a dupe of #2293

[wez]

Can you start wezterm with WAYLAND_DEBUG=1 set in the environment, reproduce this, and share the logs?
That may help to pinpoint what is happening at the wayland level.

[wez]

Running under wayfire, I see:

wayland-monitor-switch-wezterm-log.txt

@emersion, @vberger: I wonder if you have some insights into this? It sounds similar to https://source.puri.sm/Librem5/phoc/-/issues/13 and swaywm/wlroots#1379

From what I can tell (see attached logs), zwlr-output-management hands out info about a head, finishes with it, and then later when unplugging and replugging the monitor, a not a valid new object id is generated for a head event that reuses that previously finished id.

Note that the OP on this issue encounters an error with data_offer rather than head.

There are actually 3 wezterm issues open around this at the moment; the other two are:

• crash when switching monitor output #2293
• All wezterm instances crash after some time when idle #2360 (I'm guessing; there's not enough info in that report, but it seems likely a similar cause)

Am I doing something wrong with how I'm binding to and handling these events?
Am I colliding with something in SCTK?

The relevant code in wezterm is in this file, in case it is helpful:
https://github.com/wez/wezterm/blob/main/window/src/os/wayland/output.rs#L275

[emersion]

A client like wezterm shouldn't use the wlr-output-management protocol. This protocol is reserved for output configuration tools.

[wez]

Understood, but what about the data_offer variant of this? Both sound like an issue with id reuse. I'm not sure if that is due to me doing something wrong in terms of manipulating the wayland protocol objects or something else.

That particular error sounds similar to swaywm/wlroots#1379 and thus swaywm/wlroots#1041

[elinorbgr]

From what I can tell (see attached logs), zwlr-output-management hands out info about a head, finishes with it, and then later when unplugging and replugging the monitor, a not a valid new object id is generated for a head event that reuses that previously finished id.

Given the logfile and the wlr_output_management_protocol XML, I see potentially two issues here (setting aside the question of whether wezterm should or not use that protocol):

• Once receiving the .finished() event, wezterm should send a zwlr_output_head_v1.release request to destroy the object and avoid clogging up the protocol state with now-inert objects
• It appears sway reuses the id even though the client did not destroy the object yet, which seems like a sway bug ?

[emersion]

It appears sway reuses the id even though the client did not destroy the object yet, which seems like a sway bug ?

No, it's a fundamental race in the protocol v2, fixed in v3 with that release request.

[elinorbgr]

Ah, prior to v3, the finished event was the destructor? Okay that makes sense.

[wez]

I see; and the wayland-protocols crate doesn't expose that version of the protocol, which is why I couldn't find that release request.
Is the data_offer likely a direct consequence of the above, or should I go looking for a similar pattern/problem in how wezterm interacts with those as well?

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[titilambert]

Thanks ! it's fixed with the latest stable !

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.