sway freezes with xwayland app: infinite loop/recursion of `xwm_selection_send_data`

[japaric]

Hello. I'm using ardour in sway using xwayland (ardour uses gtk2 (I think) so it's not wayland native) and sway is freezing when I open a window from within ardour, be the window from ardour itself or from one of the plugins that it manages. That is the trigger but I haven't figured out the pre-condition because it doesn't freeze on the first window I open; sometimes it's the 20th window I open and sometimes it's the 200th one. However, I believe the trigger it's always a window that contains an input text field that contains some initial text.

I captured some debug logs and it seems to me that xwm_selection_send_data is being in a loop or unbounded recursion because this log keeps repeating. Each time xwm_selection_send_data is called some list appears to be getting bigger and bigger because this other log is printed once, then twice, etc. on each invocation of xwm_selection_send_data.

---

Please fill out the following:

• Sway Version:

  $ swaymsg -t get_version
  sway version 1.7

and wlroots 0.15.1 according to my package manager

• Debug Log:

The full file is ~100 MB because a set of log messages keeps repeating over and over. I'm including the first 2,000 lines; it should be sufficient to see the repeating behavior. I have a local copy of the log file if more data from it it's needed. https://gist.github.com/japaric/256422d730b4745ebd5aeefe1af09c3b

• Configuration File:

I used the default configuration

• Stack Trace:

Not applicable

• Description:
  • open terminal (foot)
  • launch ardour6 from terminal -- this instance segfaulted (that was the first time I saw ardour6 segfault) but I think that's unrelated to the bug report so ignore that part in the debug logs
  • launch ardour6 from terminal a second time
  • with the mouse select (highlight) some text in the terminal (foot) -- this puts the text in some clipboard (the selection?) buffer
  • open a (floating) window (from a menu) within ardour. this window contains an input text field
  • middle click within the input text field -- this should paste the text that was highlighted in the terminal
  • sway freezes

I was not able to reproduce the bug with those exact steps a second time.

In general, I have run into the bug sometimes within 15 minutes of using ardour and sometimes after 1 hour; the issue doesn't seem super deterministic to me. In all those instances I did not press middle click within the ardour window but rather observed the freeze as soon as the ardour window popped up. some ardour windows have input text field with some initial text and when the window goes into focus that initial text is selected -- that may be related. I do have a debug log of that other failure mode (middle click was not pressed) but I didn't use the default configuration and the freeze happened after one hour of usage so the log is longer that the uploaded one; I can share a fragment of that other debug log if needed but the same set of log messages repeats endlessly in that one.

[maxigaz]

I believe I ran into the same problem with Ardour 7.0 and Sway 1.7 under Arch Linux.

After using Ardour for 15-45 minutes, when I brought up the window for adding a new MIDI/Audio track (which contains a text input), Sway became unresponsive to any mouse and keyboard events (I couldn't even switch to another TTY with Ctrl-Alt-F2) and the screen also froze. On another occasion, the same thing happened when I double clicked on a track's name in order to rename it (which, again, shows a text input).

Unfortunately, both happened randomly and I couldn't save any logs because of the keyboard not working. (The best thing I could do is pressing the power button on the PC, which did initiate a graceful shutdown process.)

[Xyene]

I wonder if we should cancel any pending transfers for a given PID if it starts a new transfer. Here it looks like the application is just requesting the clipboard over and over, without ever reading from sway's response, so sway just accumulates a ton of transfers.

Basically, extend https://github.com/swaywm/wlroots/pull/2428 to filter by PID rather than requestor window.

This wouldn't fix the app, but it might prevent sway from hanging.

[emersion]

I'm not convinced this is a buggy app. There might be something wrong inside wlroots.

[Xyene]

There might be something wrong inside wlroots.

My money is on this too (wild guess from looking at the logs: maybe we get the requested mimetype incorrect and the other side retries infinitely) and we should investigate accordingly, but in any case "the compositor hangs" is an extra bad failure mode (especially because a buggy app could trigger this, even if that's not necessarily what's going on here).

[ThomChroma]

So Ardour, Gimp and PCManFM (https://github.com/swaywm/sway/issues/7139), all using GTK2 (even on River? https://github.com/riverwm/river/issues/734), it looks like a pattern. I can't do anything with Gimp anymore either.

[filmor]

I am experiencing a similar issue with JetBrains IDEs, I'll try to capture debug logs to verify it's the same one. It happens when pasting, though, so it fits the problem description.

[emersion]

It would maybe help to run the app inside x11trace to understand what kind of X11 property changes it's doing when busy-looping.

[alexhoode]

Happens to me constantly with JetBrains IDEs as well. Anybody has a workaround/fix?

[ToxicMushroom]

It would maybe help to run the app inside x11trace to understand what kind of X11 property changes it's doing when busy-looping.

Would that be https://aur.archlinux.org/packages/xtrace or something else ? I've obtained a log of gimp 2.10.36 hanging sway using that x11trace I mentioned but it has no timestamps https://0x0.st/Xr3V.log.

I'm currently able to consistently reproduce (3 times in a row so far) using file > open recent > selecting the code oss icon.png and then trying to export as, it opens that menu and hangs,