Shared Clipboard failing; Guest to Host -> fixed in 5.2 builds after Nov 10 2017

[philip]

The "Guest to Host" shared clipboard functionality is failing for me with VirtualBox 5.1.2. I have an OS X 10.11.6 host, with an LUbuntu 16.04 guest. Both "Guest to Host" and "Bidirectional" settings behave as if only "Host to Guest" is allowed.

I had reported this during the Beta phase here: ​https://forums.virtualbox.org/viewtopic.php?f=15&t=78285

Note: It is possible to copy text on the guest, then paste into the guest (i.e., the guest's clipboard works fine within the guest itself) but contents do not make it to the shared clipboard. Also, the shared clipboard does work fine as "Host to Guest".

[Socratis]

I tested it with VirtualBox 5.1.3 build 110033 and with Ubuntu 12.04 (32-bit) and Mint 17 (64-bit). No problems observed. Clipboard copy/paste is working as it is supposed to, back and forth.

[Thomas Törnblom]

I had this problem with 5.1.6 and thought it was solved on 5.1.8, but it appears that guest->host works for a while then stops. Host->guest and guest->guest works.

Restarting "/usr/bin/VBoxClient --clipboard" brings it back to life again, for a while.

I am running a Solaris 12 guest on MacOS X 10.11.6.

[tkvb]

It may have something to do with copying rich text to the clipboard, it seems to break VBoxClient clipboard and it needs to be restarted. At least that's what I'm seeing in my setup, CentOS 7 guest, as soon as I copy some rich text to the clipboard, host/guest copy/paste functionality is toast until I restart VBoxClient --clipboard.

[Michael Thayer]

It would be interesting to know if enabling extended logging in VBoxClient<1> produces any additional information (the original reporters please, not @tkvb, as you have already reported your issue elsewhere, and this could be different issues). And please attach a host log file (see ticket creation guidelines<2>).

1. https://www.virtualbox.org/wiki/X11Clipboard
2. https://www.virtualbox.org/newticket

[philip]

I am experiencing the same as tkvb. The log isn't showing anything useful after a lot of copy-n-pasting, only:

    Shared clipboard: Initializing X11 clipboard backend
    Shared clipboard: Starting shared clipboard thread

I do have vague memories of wondering why it seemingly failed after copying text from my browser, but not the terminal.

[philip]

The aforementioned bug by tkvb is Bug #16242, which contains useful information related to this problem.

[philip]

Host:   macOS 10.12.6 (16G1036)
Guest:  lUbuntu 16.04.3 LTS (X.Org X Server 1.18.4)
VB:     5.1.30 (same version for guest additions and extensions)

Copying plain text (from guest) works fine initially. However, copying rich text once breaks the clipboard mechanism (for rich or plain).

The logs:

Starting VirtualBox:

---

vboxClipboardConnect: 
Shared clipboard: Initializing X11 clipboard backend
ClipStartX11: 
Shared clipboard: Starting shared clipboard thread
vboxClipboardConnect: g_ctx.client=65 rc=VINF_SUCCESS
vboxClipboardMain: Starting guest clipboard service

---

Copying plain text appends this (works):

---

void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
clipConvertX11Targets: pValue=00007f2548000fe0, *pcLen=10, *atomType=4
clipUpdateX11Targets: called
clipReportFormatsToVBox: clipReportFormatsToVBox format: 1
clipReportFormatsToVBox: clipReportFormatsToVBox txt: 1, bitm: 0, html:0, u32VBoxFormats: 1
ClipReportX11Formats: u32Formats=1
vboxClipboardMain: VBOX_SHARED_CLIPBOARD_HOST_MSG_READ_DATA fFormats=1
clipQueueToEventThread: proc=0000000000406bf0, client_data=0000000002068c00
ClipReportX11Formats: rc=VINF_SUCCESS
processed host event rc = 0
vboxClipboardReadX11Worker: pReq->mFormat = 01
vboxClipboardReadX11Worker: status VINF_SUCCESS
clipDrainWakeupPipe: called
clipConvertX11CB: pReq->mFormat=01, pReq->mTextFormat=1, pReq->mBitmapFormat=0, pReq->mHtmlFormat=0, pReq->mCtx=00000000020454a0
clipUtf8ToWinTxt: pcSrc=00007f2548000f00, cbSrc=31, ppwszDest=00007f25520be838
clipUtf16ToWinTxt: pwcSrc=00007f2548000f90, cwcSrc=31, ppwszDest=00007f25520be838
clipUtf16ToWinTxt: converted string is I AM BEING COPIED FROM TERMINAL
clipUtf16ToWinTxt: returning VINF_SUCCESS
clipUtf16ToWinTxt: *pcbDest=64
clipUtf8ToWinTxt: Returning VINF_SUCCESS
clipUtf8ToWinTxt: *pcbDest=64
vboxClipboardSendData: u32Format=1, pv=00007f25480012b0, cb=64
vboxClipboardSendData: rc=VINF_SUCCESS
clipConvertX11CB: rc=VINF_SUCCESS

---

Copying rich text the first time appends this:

---

void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
clipConvertX11Targets: pValue=00007f32440012b0, *pcLen=12, *atomType=4
clipUpdateX11Targets: called
clipReportFormatsToVBox: clipReportFormatsToVBox format: 5
clipReportFormatsToVBox: clipReportFormatsToVBox txt: 1, bitm: 0, html:7, u32VBoxFormats: 5
ClipReportX11Formats: u32Formats=5
vboxClipboardMain: VBOX_SHARED_CLIPBOARD_HOST_MSG_READ_DATA fFormats=5
clipQueueToEventThread: proc=0000000000406bf0, client_data=0000000000be5ac0
ClipReportX11Formats: rc=VINF_SUCCESS
processed host event rc = 0
vboxClipboardReadX11Worker: pReq->mFormat = 05
vboxClipboardSendData: u32Format=0, pv=0000000000000000, cb=0
vboxClipboardSendData: rc=VINF_SUCCESS
vboxClipboardReadX11Worker: status VERR_NOT_IMPLEMENTED
clipDrainWakeupPipe: called

---

Subsequent copies (rich or plain) appends this:

---

void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers

---

[Michael Thayer]

It would be good if you could provide the whole log file as well, although of course your analysis is helpful. Perhaps you could actually add comment lines into the log file. Regarding the subsequent copies, is that the only text which gets appended?

[Michael Thayer]

Actually I was able to reproduce it by simulating what your Mac host sends on my Linux host.

[Michael Thayer]

I am uploading test builds<1> for the development branch (current 5.2) which I think should fix this. They should be available in half an hour or so. You should re-install the Guest Additions as well.

1. https://www.virtualbox.org/wiki/Testbuilds

[philip]

Thank you Michael, confirmed that it's fixed in the test builds! Woohoo!

Although it does not matter now, that was the entire log file... I simply split it up into chunks separated by action.

Again, thanks for tackling this bug :)