Does copy between native wayland apps work? E.g. gedit and gnome-terminal.

If X11 apps are only affected then that narrows it down significantly.

I tried from a tab in VSCode to another tab in the same program, I was able to replicate the issue I reported originally.

When pasting to gedit, I don't really think I had this problem, but... honestly I tried this twice in gedit and it just froze, after gedit froze, vscode froze too and I was just not able to do anything anymore.

instead of lorem ipsum I tried "asdf " repeated 10 times horizontally and 2560 times vertically, this is where I saw the weird behavior VSCode pasting to VSCode too. Since gedit froze I'm not able to test anything anymore and I have to restart the container :/

This issue seems related to virtio-wayland. Considering that the length of the queue is 16 entries of 4096 bytes each and the header for each entry in the queue is 16 bytes which means that 16 * 4096 (total bytes) - 16 * 16 (header bytes) =  65280 bytes are available for clipboard data. Combining that with the lockup of all wayland applications that you observed, this is evidence that the queue gets filled completely, but a deadlock is preventing it from being read.

I've got a fix under review.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/crosvm/+/92068bca00d7499dc789527b90efdf3daed2e927

commit 92068bca00d7499dc789527b90efdf3daed2e927
Author: Zach Reizner <zachr@google.com>
Date: Thu Jun 07 23:52:39 2018

wl: do not close FDs that were hungup

Before this CL, the WlState object would close VFDs that had been hungup
on the remote end as a means to removing the underlying FD from the
PollContext. However, this has some unintended side-effects. For one,
the guest would later try to delete the VFD after it was closed, which
was a double-free. Another was that every pending message that was
waiting to enter the virtio queue would get dropped if it was destined
for the closed VFD. This was especially bad if the virtio queue became
full because data would get dropped when a VFD was hungup before the
guest had any chance to read it.

This CL leaves the hungup VFDs (and therefore their pending message) as
is, but removes it from the PollContext if there is nothing left to read.
No data is removed until after the guest explicitly closes the VFD.

TEST=paste 100k characters into a guest app from Chrome
BUG= chromium:849317 

Change-Id: I20e3bc7c32c3f654f88f6ef9cdfcb853f2d52f09
Reviewed-on: https://chromium-review.googlesource.com/1088308
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/92068bca00d7499dc789527b90efdf3daed2e927/devices/src/virtio/wl.rs

This should be fixed with the next dev image of Chrome OS.