Would be great to know the X11 app(s) they were interacting with. I find it weird that such thing happens in a loop at all.

I also suffer from this bug (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810969).

In my case, this mainly occurs when using the “xclip” utility to retrieve X11's clipboard selection, but as far as I know, it can also occur when pasting to a native wayland surface (such as the “sakura” terminal emulator), but I'm not sure which application owns the selection when it occurs, neither if it is an X11 or native wayland app.

The X11 apps I am using are mostly chromium, CoqIDE, gajim and xclip.
I have found no way of reliably triggering the bug.

I ran into this bug too on Debian Testing: gnome-shell (3.18.1-1) was not actually using all the CPU but I got 3GB worth of 'Error transfering wayland clipboard to X11: Operation was cancelled' traces in /var/log/syslog.

At the time this happened there were two X11 sessions:
 * One was obviously inactive and had at most a Firefox browser running (Iceweasel 44.0-1 really).
 * The other was running the same Firefox, browsed to a website with a video, and had been running AisleRiot (1:3.18.2-1).

is any of you able to reproduce this with 3.19.x ?

I can reproduce this issue within a day or so.  I'm using Ubuntu 16.04 with mutter 3.18.2-0ubuntu1.  The application it's interacting with is definitely chrome and/or chromium.  I think these are the steps:

1.  I think the wayland clipboard has to be empty.
2.  In chrome, right click inside of the address bar.  If nothing happens, then you've reproduced the issue.
3.  After 5 minutes or so, of high CPU usage, and tons of syslog errors, a right-click menu should appear.

Here are the the log messages I get:

Mar  1 09:43:38 gnome-session[1519]: (gnome-shell:1531): mutter-WARNING **: Error transfering wayland clipboard to X11: Operation was cancelled
Mar  1 09:43:38 gnome-session[1519]: message repeated 1065 times: [ (gnome-shell:1531): mutter-WARNING **: Error transfering wayland clipboard to X11: Operation was cancelled]
Mar  1 09:43:38 gnome-session[1519]: (gnome-shell:1531): mutter-CRITICAL **: Failed to open pipe: Too many open files
Mar  1 09:43:38 gnome-session[1519]: (gnome-shell:1531): mutter-WARNING **: Error transfering wayland clipboard to X11: Operation was cancelled
Mar  1 09:43:48 gnome-session[1519]: message repeated 1784 times: [ (gnome-shell:1531): mutter-WARNING **: Error transfering wayland clipboard to X11: Operation was cancelled]
Mar  1 09:43:48 gnome-session[1519]: (gnome-shell:1531): mutter-CRITICAL **: Failed to open pipe: Too many open files

I caught a good strace of mutter while it was happening.  I'll attach it.

Created attachment 322787 [details]
strace of mutter during wayland clipboard X11 error

(In reply to Brian Vincent from comment #5)
> I can reproduce this issue within a day or so.  I'm using Ubuntu 16.04 with
> mutter 3.18.2-0ubuntu1.  The application it's interacting with is definitely
> chrome and/or chromium.  I think these are the steps:
> 
> 1.  I think the wayland clipboard has to be empty.
> 2.  In chrome, right click inside of the address bar.  If nothing happens,
> then you've reproduced the issue.
> 3.  After 5 minutes or so, of high CPU usage, and tons of syslog errors, a
> right-click menu should appear.

I'm installing now chromium in order to try.

> 
> Here are the the log messages I get:
> 
> Mar  1 09:43:38 gnome-session[1519]: (gnome-shell:1531): mutter-WARNING **:
> Error transfering wayland clipboard to X11: Operation was cancelled
> Mar  1 09:43:38 gnome-session[1519]: message repeated 1065 times: [
> (gnome-shell:1531): mutter-WARNING **: Error transfering wayland clipboard
> to X11: Operation was cancelled]
> Mar  1 09:43:38 gnome-session[1519]: (gnome-shell:1531): mutter-CRITICAL **:
> Failed to open pipe: Too many open files

Specifically these are very fishy. The next time you reproduce it would be great if you could attach here the output of lsof -p $gnome_shell_pid or ls -l /proc/$gnome_shell_pid/fd/

Created attachment 322813 [details]
ls -l /proc/gnome-shell-pid/fd during this bug

Created attachment 322814 [details]
lsof during this bug

This was actually pretty hard to get.  As the strace shows, the file descriptors don't stay around for very long.  Furthermore, I think gnome-shell was preventing me from pressing enter at the correct moment.

As the strace shows, the fds are all from pipe.

I'm attaching some patches here. Note that I've been unable to reproduce yet though (Using mutter and gtk+ 3.19.x).

The first two patches will fix the chromium popup menu not showing. There were paths where the Xwayland side would not get notified of the data source disappearing, so it would not update selection ownership appropriately. Notifying this correctly will stop confusing chromium here.

The last one fixes possible situations where one "read from wayland" operation cancels the next one that replaced it.

However, as I said in comment #1, I see no way for this to be triggered by mutter alone. There has to be an X11 client actually flooding mutter with SelectionRequest events. I guess this extreme could be confirmed by attaching to the process with gdb (NB, do it outside the wayland session, that'll block everything), and setting breaks on XConvertSelection and meta_xwayland_selection_handle_selection_request. If the second is hit continuously and the first doesn't happen, then that's it.

Note that there is only one current read operation at any given time. The only scenario where I see it conceivable that the pipes created here are those causing "too many files open" errors is that we receive so many SelectionRequest events that we have many outstanding and already cancelled wayland_data_read_cb() callbacks. This again requires a flood situation.

Also, the situations where I could reproduce the chromium menu not popping up seem to go in the opposite direction than this bug. If a selection data source disappears, data_device->selection_data_source will still be NULL even if we didn't announce the clipboard owner disappearing to the X11 side. X11 apps may still think there's an alive clipboard owner but requests are just no-op in mutter, pipes are not even created in this situation.

So my line of investigation currently is that we trigger a misbehavior in certain apps that cause such storm of SelectionRequest events in response. If someone could confirm with the gdb steps instructions would be great.

Created attachment 322882 [details] [review]
wayland: Emit signal on selection data source destruction

This is necessary for the X11 side to catch up, and unset the selection
ownership on our window that represents the wayland side in X11 selection.

Created attachment 322883 [details] [review]
wayland: Emit signal on primary selection data source destruction

This is necessary for the X11 side to catch up, and unset the primary
selection ownership on our window that represents the wayland side in
X11 selection.

Created attachment 322884 [details] [review]
xwayland: Fix possible cancellation of wayland data sources

If we receive multiple SelectionRequest events, we'll end up replacing the
former WaylandSelectionData at a time when an async read has been issued.
This will cause the cancellation of the previous operation.

But the wayland_data_read() callback will attempt to just remove the
current wayland data again on error, which will not be the one we're
cancelling, so the new operation will just be cancelled too.

Also, cancellation is no longer warned about. As the wayland selection
has been replaced at this time, we can just return here.

Jonas, or Rui, could you review these patches ?

Review of attachment 322884 [details] [review]:

looks fine

::: src/wayland/meta-xwayland-selection.c
@@ +683,3 @@
       g_error_free (error);
 
+      if (data && data->stream == G_INPUT_STREAM (object))

Took a little while to convince myself that data here could be a different instance but that's because it is the MetaSelectionBridge that gets passed as user_data, so the WaylandSelectionData intance we get here might already be different.

Review of attachment 322883 [details] [review]:

lgtm

Review of attachment 322882 [details] [review]:

lgtm

(In reply to Rui Matos from comment #15)
> Review of attachment 322884 [details] [review] [review]:
> 
> looks fine
> 
> ::: src/wayland/meta-xwayland-selection.c
> @@ +683,3 @@
>        g_error_free (error);
>  
> +      if (data && data->stream == G_INPUT_STREAM (object))
> 
> Took a little while to convince myself that data here could be a different
> instance but that's because it is the MetaSelectionBridge that gets passed
> as user_data, so the WaylandSelectionData intance we get here might already
> be different.

Yeah, exactly. TBH, replacing the WaylandSelectionData should always cancel the previous operation, so it should always fall into the return added by the patch, this is mostly a paranoia check.

Pushed all 3 patches. Leaving the bug open, waiting for someone to confirm.

Attachment 322882 [details] pushed as 169f0e7 - wayland: Emit signal on selection data source destruction
Attachment 322883 [details] pushed as da28d7a - wayland: Emit signal on primary selection data source destruction
Attachment 322884 [details] pushed as a94e640 - xwayland: Fix possible cancellation of wayland data sources

I hit this case even with those patches applied. I was using Firefox when it happened, mutter took 100% CPU and attaching gdb to the process showed that it either was in some IO function or somewhere in the Xwayland clipboard bridge code. So sadly it doesn't seem fixed yet.

(In reply to Jonas Ådahl from comment #20)
> I hit this case even with those patches applied. I was using Firefox when it
> happened, mutter took 100% CPU and attaching gdb to the process showed that
> it either was in some IO function or somewhere in the Xwayland clipboard
> bridge code. So sadly it doesn't seem fixed yet.

Bummer. Could you set up breaks as I described in comment #10?

(In reply to Carlos Garnacho from comment #21)
> (In reply to Jonas Ådahl from comment #20)
> > I hit this case even with those patches applied. I was using Firefox when it
> > happened, mutter took 100% CPU and attaching gdb to the process showed that
> > it either was in some IO function or somewhere in the Xwayland clipboard
> > bridge code. So sadly it doesn't seem fixed yet.
> 
> Bummer. Could you set up breaks as I described in comment #10?

It happened at a very inconvenient time, so I just attached and stopped mutter a few times just to see what it was, then restarted Firefox and continued with what I had to finish. I have this backtrace of one of the ^C:s I did:

+ Trace 236029

Did we get to the bottom of this ? How often does it happen ?

(In reply to Matthias Clasen from comment #23)
> Did we get to the bottom of this ? How often does it happen ?

I have only ever seen it once, and my default web browser runs via Xwayland.

Hello!

I'm getting this bug too. For me it's not directly related to using the clipboard, and most frequently happens when opening / closing an application or when I 'alt-tab' from one app to another.

It happens every few hours.

My mouse starts stuttering and becomes slower and slower to the point of stopping to respond at all. When I check /var/log/messages there is gigabytes worth of the line:

> Apr  3 01:25:05 frosty gnome-session[1715]: (gnome-shell:1723): mutter-WARNING **: Error transfering wayland clipboard to X11: Operation was cancelled

I'm on debian (Debian GNU/Linux stretch/sid 64-bit). The system does not crash and is remotely accessible. Restarting GDM does restore the system.

(In reply to César de la Cal from comment #25)
> Hello!
> 
> I'm getting this bug too. For me it's not directly related to using the
> clipboard, and most frequently happens when opening / closing an application
> or when I 'alt-tab' from one app to another.
> 
> It happens every few hours.
> 
> My mouse starts stuttering and becomes slower and slower to the point of
> stopping to respond at all. When I check /var/log/messages there is
> gigabytes worth of the line:
> 
> > Apr  3 01:25:05 frosty gnome-session[1715]: (gnome-shell:1723): mutter-WARNING **: Error transfering wayland clipboard to X11: Operation was cancelled
> 
> I'm on debian (Debian GNU/Linux stretch/sid 64-bit). The system does not
> crash and is remotely accessible. Restarting GDM does restore the system.

This is still gnome-shell/mutter 3.18, isn't it? Would be interesting if you found out the X11 application that is inducing this for you, you could perhaps try to kill X applications one by one and see if gnome-shell returns to normal activity.

Also, if you have remote access when this happens, it'd be great if you tried setting up breaks in gdb as I described in the 4th paragraph in comment #10 to confirm some suspicions, it might require x11/mutter debug packages.

(In reply to Carlos Garnacho from comment #26)
> 
> This is still gnome-shell/mutter 3.18, isn't it? Would be interesting if you
> found out the X11 application that is inducing this for you, you could
> perhaps try to kill X applications one by one and see if gnome-shell returns
> to normal activity.
> 
> Also, if you have remote access when this happens, it'd be great if you
> tried setting up breaks in gdb as I described in the 4th paragraph in
> comment #10 to confirm some suspicions, it might require x11/mutter debug
> packages.

Yes, it's Gnome shell Version 3.18.2 - It's debian unstable though.

I will try killing the different UI applications I have open when it happens again, but I'm afraid that I need closer guidance with the gdb stuff. I'm just a PHP programmer :P, last time I used gdb was in university and I don't think it was anything beyond entry level stuff

It usually happens every few hours for me, so expect a message later today.

(In reply to César de la Cal from comment #27)
> (In reply to Carlos Garnacho from comment #26)
> > 
> > This is still gnome-shell/mutter 3.18, isn't it? Would be interesting if you
> > found out the X11 application that is inducing this for you, you could
> > perhaps try to kill X applications one by one and see if gnome-shell returns
> > to normal activity.
> > 
> > Also, if you have remote access when this happens, it'd be great if you
> > tried setting up breaks in gdb as I described in the 4th paragraph in
> > comment #10 to confirm some suspicions, it might require x11/mutter debug
> > packages.
> 
> Yes, it's Gnome shell Version 3.18.2 - It's debian unstable though.
> 
> I will try killing the different UI applications I have open when it happens
> again, but I'm afraid that I need closer guidance with the gdb stuff. I'm
> just a PHP programmer :P, last time I used gdb was in university and I don't
> think it was anything beyond entry level stuff
> 
> It usually happens every few hours for me, so expect a message later today.

Thanks, much appreciated. The gdb steps once you gained remote access are:

- Figure out the pid of your user gnome-shell
- Run gdb with the pid you found out like: 

  gdb /usr/bin/gnome-shell 1234

and in the gdb prompt:

  b meta_xwayland_selection_handle_selection_request
  b XConvertSelection
  c

Now each time you hit 'c' (means "continue") it will continue execution till one of the functions where we've set up breaks are called, you'll need to continue a few times to see what are the breaks that happen most frequently.

My theory of this bug is that gnome-shell/mutter can't fall into this alone, it needs an X11 application actually doing that many clipboard requests, so meta_xwayland_selection_handle_selection_request will be called really frequently, but no call to XConvertSelection will be seen.

If OTOH you see gdb breaking on XConvertSelection when this happens, additionally to the above, then there is a possibility that this is self-induced, which is something quite unexpected but would set us on the track to something.

Oh, also forgot to ask, are you maybe running a clipboard manager daemon like GPaste, Klipper or somesuch?

So, it just happened again. Here's what happened: I was switching windows when the mouse started stuttering and it froze, four apps were running.

- Firefox
- Netbeans
- Skype
- Dropbox

As you said I started killing the different processes. First I killed Firefox, nothing seemed to happen. Then I killed Java (Netbeans) and again nothing seemed to happen.

When I killed Skype the screen refreshed, but the system would not react right when it happened. It took several seconds for it to start moving the cursor again.

I'm not sure therefore if the problem is related to Skype running (because I was not actively using it) and because the system took quite some time to recover it may be Firefox or Netbeans which were keeping the system busy.

If it happens again I will invert the sequence and kill Skype first, since it's my best bet at this point in time. (And the Skype client for Linux is garbage)

As far as I know I don't use any special clipboard management, should I check somehow? Also, would this imply that I need to press c somewhere whenever an application uses the clipboard?

What data would you need from the debugger once I get there?

The clipboard code for GNOME Shell Wayland is inadequate. This bug here is only one of the many troubles it causes us.

When this bug happens, there is no clear way of determining what GNOME Shell is up to. I have presently 3 gnome-settings-daemon at 82% cpu each.

The other two bugs that are prevalent is 100% cpu on copy, and clipboard in-operational when not empty.

In those other cases one can empty the clipboard using:
install: sudo apt-get install xclip; touch ~/blank
then whenever clipboard is not happy:
xclip -selection clipboard ~/blank

That does not help for this bug.

If GNOMErs can;t figure out what is causing this bug, please implement better logging or some signal dumping state for troubleshooting. It is unclear to me what gnome-settings-daemon is trying to do, why it takes 3 processes doing it and what I did to set the thing off.

The cause seems to be buggy implementation of multiple clipboards. One could do a rewrite and put legacy X/non-Wayland code as a shim. If anyone tries to paste between for example chromium-browser and Libreoffice, it is clear that the clipboard has been buggy for years forcing a paste-copy in gedit in between.

> One could do a rewrite

Are you working on that, then ?

> forcing a paste-copy in gedit in between

Now that you mention it. I had this happen yesterday, very annoying. Was trying to log into a server via SSH and passwords I copied from KeepassX would not paste in the terminal or Gedit.

It would paste onto my IDE but when copying it from there it would not paste anywhere else.

Today my system has been bug free for quite a bunch of hours. It crashed again yesterday though, Skype was not involved this time. For me it seems that it's not really related to one X application in particular.

(In reply to Carlos Garnacho from comment #28)
> (In reply to César de la Cal from comment #27)
> > (In reply to Carlos Garnacho from comment #26)
> > > 
> > > This is still gnome-shell/mutter 3.18, isn't it? Would be interesting if you
> > > found out the X11 application that is inducing this for you, you could
> > > perhaps try to kill X applications one by one and see if gnome-shell returns
> > > to normal activity.
> > > 
> > > Also, if you have remote access when this happens, it'd be great if you
> > > tried setting up breaks in gdb as I described in the 4th paragraph in
> > > comment #10 to confirm some suspicions, it might require x11/mutter debug
> > > packages.
> > 
> > Yes, it's Gnome shell Version 3.18.2 - It's debian unstable though.
> > 
> > I will try killing the different UI applications I have open when it happens
> > again, but I'm afraid that I need closer guidance with the gdb stuff. I'm
> > just a PHP programmer :P, last time I used gdb was in university and I don't
> > think it was anything beyond entry level stuff
> > 
> > It usually happens every few hours for me, so expect a message later today.
> 
> Thanks, much appreciated. The gdb steps once you gained remote access are:
> 
> - Figure out the pid of your user gnome-shell
> - Run gdb with the pid you found out like: 
> 
>   gdb /usr/bin/gnome-shell 1234
> 
> and in the gdb prompt:
> 
>   b meta_xwayland_selection_handle_selection_request
>   b XConvertSelection
>   c
> 
> Now each time you hit 'c' (means "continue") it will continue execution till
> one of the functions where we've set up breaks are called, you'll need to
> continue a few times to see what are the breaks that happen most frequently.
> 
> My theory of this bug is that gnome-shell/mutter can't fall into this alone,
> it needs an X11 application actually doing that many clipboard requests, so
> meta_xwayland_selection_handle_selection_request will be called really
> frequently, but no call to XConvertSelection will be seen.
> 
> If OTOH you see gdb breaking on XConvertSelection when this happens,
> additionally to the above, then there is a possibility that this is
> self-induced, which is something quite unexpected but would set us on the
> track to something.

Unfortunately, I don't have debug symbols for mutter, and they don't appear to be in the distribution.
So, I only set the breakpoint to XConvertSelection.

It is actually called a *lot*: “c 1000” returns in less than a second.

(gdb) C
Continuing.

Breakpoint 1, XConvertSelection (dpy=0x16b9170, selection=323, target=31, property=482, requestor=2097155, time=0)
    at ../../src/ConvSel.c:40
40      in ../../src/ConvSel.c

Only “target” seems to change across calls.

I tried a lot of things (“echo foo | xclip -in -selection clipboard” that has been a good workaround in the past, killing various X11 applications), couldn't get it back to normal.
Ended up killing chromium, that didn't work, but several
minutes later, gnome-shell went back to normal CPU usage… but
the screen stayed black. Attaching gdb, it is still responsive,
as it makes exactly two XConvertSelection by ctrl+v presses!

There has been a segfault from a Gtk2 application during the
100% CPU thing (or shortly after):
[403699.465231] gajim[7258]: segfault at 7ffe32896fd0 ip 00007ff23a60e085 sp 00007ffe32896fc0 error 6 in libgobject-2.0.so.0.4800.0[7ff23a5f9000+52000]

I changed VTs back and forth, and gnome-shell went back at 100% CPU usage for a while before getting somewhat responsive again.
As I type this, it goes back and forth between being responsive and not, but XConvertSelection is never called.

The only graphical apps I can think of that are running right now are sakura, gnome-shell, system-printer-applet, and a zenity dialog that isn't displayed yet, telling me that sakura has hung:
thib      7486  0.0  0.5 502176 40748 tty2     Sl+  20:19   0:00 zenity --question --display :0.0 --class mutter-dialog --title  --text <big><b>« sakura » ne répond pas.</b></big>  Vous pouvez patienter un instant pour continuer ou forcer l'application à quitter définitivement. --ok-label _Attendre --cancel-label _Forcer à quitter --icon-name face-sad-symbolic

I am still running gnome-shell 3.18.1-1 and libmutter 3.18.3-2 from Debian.

Same problem for me, but only for keepass2 - most of the times when I'm trying to copy password, Keepass2 window is locking up, gnome-shell 100% load, and no text in clipboard. But it seems that keepass is still clearing the cliboard in few seconds (for security), so CPU load drops to 0, but keepass window is still locked.

Oh, and it's original keepass2, under mono, not keepassx

I did not have the chromium-browser right-click freeze from #5 on 3.18/Ubuntu 15.10
It is present in 3.20/Ubuntu 16.04

I did have the high cpu clipboard, though, but I used xclip <<<"" as a get-around so it was not a problem to me

I also get the new fancy log statements in 3.20:
Apr 19 21:55:18 c89 org.gnome.Shell.desktop[14042]: Window manager warning: 0x1000001 (Bug 760745) appears to be one of the offending windows with a timestamp of 9515498.  Working around...
- this is an improvement

I found a pretty reliable way to reproduce this bug on my machine. Maybe this helps the devs... For some reason, for me the issue appears strongest around Netbeans.

1. Run Netbeans, edit some code.
2. Leave Netbeans open. Wait for the system to lock the session due to idle time.
3. Once the screens are black, log back into your session.
4. Focus Netbeans window
5. Profit / Crash

It crashes every time for me like this. It takes a few seconds though, and if you're fast enough and put something into the clipboard by pressing Ctrl-C inside the editor it will slow down, freeze for a few seconds and eventually come back.

This still happens on GNOME 3.20 as available in Debian, and I have found a pretty reliable way to trigger it:
1. Copy something in the clipboard
2. Lock screen
3. Unlock screen
4. Paste from clipboard
5. Enjoy the unresponsive gnome-shell

I have tried copying and pasting from both a wayland application (sakura, using Gtk3) and a X11 application (gajim, using Gtk2) with the same results.

I had other X11 applications running, but I didn't explicitly interact with them.

(In reply to Thibaut Girka from comment #38)
> This still happens on GNOME 3.20 as available in Debian, and I have found a
> pretty reliable way to trigger it:
> 1. Copy something in the clipboard
> 2. Lock screen
> 3. Unlock screen
> 4. Paste from clipboard
> 5. Enjoy the unresponsive gnome-shell
> 
> I have tried copying and pasting from both a wayland application (sakura,
> using Gtk3) and a X11 application (gajim, using Gtk2) with the same results.
> 
> I had other X11 applications running, but I didn't explicitly interact with
> them.

Works fine on Fedora 24:
gtk3-3.20.6-1.fc24.x86_64
glib2-2.48.1-1.fc24.x86_64
gnome-shell-3.20.2-1.fc24.x86_64
mutter-3.20.2-1.fc24.x86_64

I can easily hit this on a fedora 25 with a wayland session,
- run gnome-terminal
- lock the screen (I use meta-l)
- unlock
- run xclip, type random chars, ctrl+D
- press ctrl+shift+v (ie paste) in the terminal

-> this leads to a storm of pipe2() (strace) calls ending with
  gnome-shell[4564]: Failed to open pipe: Too many open files
which is wayland_selection_data_new() in meta-xwayland-selection.c in mutter source code

I'm also seeing this with a fedora 25 live cd running in a VM, (after installing strace/xclip) so should not be a side-effect of some unusual program being installed.

(In reply to Christophe Fergeau from comment #40)
> I can easily hit this on a fedora 25 with a wayland session,
> - run gnome-terminal
> - lock the screen (I use meta-l)
> - unlock
> - run xclip, type random chars, ctrl+D
> - press ctrl+shift+v (ie paste) in the terminal
> 
> -> this leads to a storm of pipe2() (strace) calls ending with
>   gnome-shell[4564]: Failed to open pipe: Too many open files
> which is wayland_selection_data_new() in meta-xwayland-selection.c in mutter
> source code

When following these steps to reproduce on a F25 wayland, I get the same error message in syslog (journald). No text is getting pasted into the terminal at all.

I can not always reproduce the 100% CPU load issue thought, but if it happens, my system completely lags or even freezes for some seconds. The lag/freeze also affects the mouse. I can reliably trigger it when I follow your steps above while having firefox with multiple tabs on youtube.com open, playing at least one video.

Installed software versions:
gtk3-3.22.1-1.fc25.x86_64
glib2-2.50.0-1.fc25.x86_64
gnome-shell-3.22.0-1.fc25.x86_64
mutter-3.22.0-2.fc25.x86_64
libwayland-client-1.12.0-1.fc25.x86_64

Created attachment 337173 [details] [review]
xwayland: Ignore selection request not meant to our internal window

There may be other windows managing selection whose events are seen in
our GDK event filter, like st-clipboard in gnome-shell, we should in
that case not interfere on Selection/SelectionRequest events that are
not meant for us.

This fixes an odd feedback loop where requesting clipboard contents from
wayland results in a XConvertRequest call and a SelectionRequest event
that is interpreted by mutter as a request from another X11 client, so
the current data source is poked for content, which happens to be the
X11 bridge, which does a XConvertRequest to get contents... This is only
broken after the many nested async operations create enough pipes and
cancellables to run out of fds.

Adding checks to ensure only events meant to our "selection owner"
window are managed prevent this unintended loop to happen in the first
place.

Review of attachment 337173 [details] [review]:

looks good. st-clipboard.c should probably have the same checks or it might act on selection events that are intended for the xwayland bridge

Comment on attachment 337173 [details] [review]
xwayland: Ignore selection request not meant to our internal window

I'm leaving the bug open for the st-clipboard fixes, the "loop" shouldn't
happen anymore though.

Attachment 337173 [details] pushed as b3eac93 - xwayland: Ignore selection request not meant to our internal window

Created attachment 337199 [details] [review]
st: Ignore filtered selection events not meant to our clipboard window

Other windows like the mutter Xwayland selection bridges might deal with
the clipboard, which would result in events visible on st-clipboard event
filters.

In order to avoid unintended results, ignore events that are not meant for
the clipboard window.

Will this also fix the "gnome-shell[4564]: Failed to open pipe: Too many open files" problem?

Yes, that's a consequence of the feedback loop I mentioned.

Review of attachment 337199 [details] [review]:

LGTM

Thanks! Pushed and closing this bug, all fixes are in place.

Attachment 337199 [details] pushed as a22e9ce - st: Ignore filtered selection events not meant to our clipboard window

*** Bug 770840 has been marked as a duplicate of this bug. ***

*** Bug 769619 has been marked as a duplicate of this bug. ***

*** Bug 758958 has been marked as a duplicate of this bug. ***

*** Bug 760294 has been marked as a duplicate of this bug. ***