By messing with capturer timings (inserting a sleep to simulate the capturer taking a long time), it's possible for
InputInjectorX11::InjectClipboardEvent()
to be called before
InputInjectorX11::Start(),
which currently causes a DCHECK. Behavior of release build is unknown.

Start(ClipboardStub) tells the clipboard implementation to start listening for local clipboard changes, passing them to the provided stub.
InjectClipboardEvent(ClipboardEvent) tells the implementation to set the local clipboard.

There seems to be nothing preventing these methods being called in the wrong order. Currently, the X11 clipboard implementation assumes that it has to listen for local changes before it will allow the clipboard to be set (because it opens the X11 display and pumps X events). The DCHECK failure is:

[1030/151502.655434:FATAL:x_server_clipboard.cc(87)] Check failed: display_. 
#0 0x0000031f8eed base::debug::StackTrace::StackTrace()
#1 0x000002f7a33a base::debug::StackTrace::StackTrace()
#2 0x000002fcdcdb logging::LogMessage::~LogMessage()
#3 0x000002d25bd0 remoting::XServerClipboard::SetClipboard()
#4 0x0000052603d2 remoting::ClipboardX11::InjectClipboardEvent()
#5 0x00000524d8f6 remoting::(anonymous namespace)::InputInjectorX11::Core::InjectClipboardEvent()

We need to fix the implementation so that it will allow clipboard injection before a ClipboardStub is provided for reporting local clipboard changes.

It may be acceptable for the implementation to drop local clipboard changes if ClipboardStub is not yet provided. But it is not acceptable to drop a clipboard-injection.