Opened 5 years ago
Last modified 17 months ago
#19226 accepted defect
VM segfaults on copy with shared clipboard
| Reported by: | udine | Owned by: | pentagonik |
|---|---|---|---|
| Component: | clipboard | Version: | VirtualBox 6.1.2 |
| Keywords: | Cc: | ||
| Guest type: | Linux | Host type: | Linux |
Description
When using the shared clipboard, all running VMs in certain states crash whenever some input it copied on the host.
Steps to reproduce:
- Start VM and login
- Open libreoffice calc on host
- Select and copy some cells => VM crashes
No messages are in the VBox log of the VM, but there are some in the journal of the host.
ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=1559 comm="ShClipboard" exe="/usr/lib/virtualbox/VirtualBoxVM" sig=11 res=1 ShClipboard[1599]: segfault at 4 ip 00007fe97c14a1ae sp 00007fe95c199cf0 error 4 in VBoxSharedClipboard.so[7fe97c143000+8000] Code: 89 c4 85 c0 78 50 48 8d 4d c0 ba 30 75 00 00 44 89 f6 4c 89 ff 67 e8 b1 c9 ff ff 41 89 c4 85 c0 78 34 48 8b 45 c0 48 8b 7b 08 <8b> 50 04 39 53 04 0f 46 53 04 48 8b 70 08 89 d2 ff 15 84 5c 00 00 audit: type=1701 audit(1579083656.742:64): auid=1000 uid=1000 gid=1000 ses=2 pid=1559 comm="ShClipboard" exe="/usr/lib/virtualbox/VirtualBoxVM" sig=11 res=1
The issue also occurs when copying from the guest, but I currently don't have a reproducer for that. Journal message on host:
SHCLX11[3662]: segfault at 8 ip 00007efc7073d3ea sp 00007efc71b6c8a0 error 4 in VBoxSharedClipboard.so[7efc70736000+8000]
Version used is 6.0.12, but the issue was also present in at least 6.1.0. Host is running Arch Linux, guest is Kali Linux (haven't tested with other combinations).
Attachments (2)
Change History (87)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
| Version: | VirtualBox 6.0.12 → VirtualBox 6.1.2 |
|---|
comment:3 by , 5 years ago
I can confirm this. I have Virtualbox 6.1.0. Host is Debian 10 with kernel 5.3. Guest was Windows 7. VM crashed while copying and pasting on the guest only (bidirectional clipboard is enabled).
dmesg on the host:
debian kernel: [34950.628667] ShClipboard[27231]: segfault at 4 ip 00007f5b1a4df1d6 sp 00007f5b1a565d00 error 4 in VBoxSharedClipboard.so[7f5b1a4d8000+8000] debian kernel: [34950.628681] Code: 41 89 c6 85 c0 78 4a 48 8d 4d c8 ba 30 75 00 00 44 89 e6 4c 89 ef e8 e9 cb ff ff 41 89 c6 85 c0 78 2f 48 8b 45 c8 48 8b 7b 08 <8b> 50 04 39 53 04 0f 46 53 04 48 8b 70 08 89 d2 e8 35 90 ff ff 48
comment:4 by , 5 years ago
Hello, I can confirm that too.
Guest Systems -- many, ArchLinux, Windows 7 Server, Windows 10 Pro, Kali Linux.
Host System: Linux vboxHost 5.4.7-arch1-1 #1 SMP PREEMPT x86_64 GNU/Linux
I7 7th generation 64 GB RAM, 11 TB SSD - no space problem, no double name problem, non of the answers in the VirtualBox forums.
And this problem has cost me sensless amounts of time.
After update to version 6.1.0 most machines crashed during login.
What did NOT help:
Downgrade to any prior version of VirtualBox. Changes in the guest machines. Updates and driver (module) changes in host or guest. Strace in many variants. Machines just did not start anymore during X login. Konsole login was ok. No dmesg leftover.
What DID help:
Making a full clone of any machine. Leaving all prior snapshots. Disable mouse interaction. (German: Allgemein (General) - Erweitert (More) - and there mouse interaction full disable. This helped, but the machines are still not stable, updating the machines sometimes leads to a state, where X just doesn't start. No .xerror log. Windows guests are more stable in starting, but are crashing immeadetly by using a double click.
Deeply annoying.
Best regards
comment:5 by , 5 years ago
Can confirm a segfault in on a Kubuntu 19.10 host and VirtualBox 6.1.2-135662~Ubuntu~eoan from the official VirtualBox repository, and a Win10 1903 guest with the latest guest tools installed - mostly happens a few seconds after I start Outlook within the guest VM:
Jan 21 12:02:56 edbook kernel: [ 6206.040448] ShClipboard[18802]: segfault at 4 ip 00007f1404189bfe sp 00007f13cb943cf0 error 4 in VBoxSharedClipboard.so[7f1404182000+8000] Jan 21 12:02:56 edbook kernel: [ 6206.040458] Code: 41 89 c4 85 c0 78 4d 48 8d 4d c0 ba 30 75 00 00 44 89 f6 4c 89 ff e8 e1 c9 ff ff 41 89 c4 85 c0 78 32 48 8b 45 c0 48 8b 7b 08 <8b> 50 04 39 53 04 0f 46 53 04 48 8b 70 08 89 d2 e8 0d 8b ff ff 48
What helps: Disabling shared clipboard altogether, but I'd love to re-enable it again, so it would be great if this could be fixed.
Edit: I also tried uninstalling and reinstalling the guest tools in the VM, but that didn't help - appears to be an issue on the host side.
comment:6 by , 5 years ago
Hi all, I have the same problem with MS Win 10 and MS Office by select and copy some cells.
Linux 5.4.0-kali2-amd64 #1 SMP Debian 5.4.8-1kali1 (2020-01-06) x86_64 GNU/Linux VirtualBox Version 6.1.0_Debian r135406 Message: segfault at 8 ip 00007fc0a8043569 sp 00007fc0636117c0 error 4 in VBoxSharedClipboard.so[7fc0a803c000+8000]
What has helped is deactivating of
drag and drop
and shared clipboard
Will there be a patch for this soon?
Best wishes
Skorupa
comment:7 by , 5 years ago
Same here, Linux host, Windows 10 guest. Virtualbox 6.1.0 r135406 (Qt5.11.3) crashes on pasting screenshot images from the linux clipboard. Copying and pasting text seems to be ok, though.
comment:8 by , 5 years ago
Hi !
Windows 10 host, Linux Mint guest When copying from host to guest => nothing happens When copying from guest to host => the destination application crashes
Regards.
comment:9 by , 5 years ago
comment:10 by , 5 years ago
Me to...
Jan 27 10:23:20 pc kernel: [ 1506.547914] VirtualBox[2301]: segfault at 20 ip 00007f4f8bb36fdf sp 00007ffecc4b66f0 error 4 in libQt5Core.so.5.9.5[7f4f8ba12000+53b000] Jan 31 14:28:46 pc kernel: [281578.691702] ShClipboard[16461]: segfault at 4 ip 00007fd87e1f33e8 sp 00007fd88c08ccf0 error 4 in VBoxSharedClipboard.so[7fd87e1ea000+d000] Feb 10 10:36:24 pc kernel: [ 9600.525395] ShClipboard[18300]: segfault at 4 ip 00007f67657813e8 sp 00007f6765a06cf0 error 4 in VBoxSharedClipboard.so[7f6765778000+d000] Feb 11 11:51:20 pc kernel: [100497.758378] ShClipboard[23834]: segfault at 4 ip 00007f72c53723e8 sp 00007f72c55f7cf0 error 4 in VBoxSharedClipboard.so[7f72c5369000+d000] Feb 13 17:09:16 pc kernel: [292375.503408] ShClipboard[14334]: segfault at 4 ip 00007f45365403e8 sp 00007f45540decf0 error 4 in VBoxSharedClipboard.so[7f4536537000+d000]
(well except for that first one probably).
Quite annoying when you depend on it for remote access and it disappears halfway during your session taking down whatever it is you were doing. (and you find you have no way to restart the virtual machine from home)
So far I'm not impressed by version 6 (haven't been able to mount my usb stick as well so far, but truth be told that function suddenly vanished in v5 before I made the switch to a whole new pc.
Current host: Xubuntu 18.04
Guest: Windows 10 (enterprise)
Virtualbox 6.1.2
by , 5 years ago
comment:11 by , 5 years ago
VirtualBox version 6.1.3 r135846 (Qt5.6.1).
I have same problem. Host is Arch Linux, Guest VM is Windows Server 2008 R2 with SP1.
Although I can't reproduce this bug in reasonable time by copying texts to host from guest and vice versa, VM will definitely crash if I use Firefox web browser and try to manipulate bookmarks by right clicking them. But this crash by Firefox and right clicking doesn't happen right away, too. It will take time.
[Feb17 09:41] ShClipboard[67592]: segfault at 4 ip 00007f8081473473 sp 00007f80816f8cb0 error 4 in VBoxSharedClipboard.so[7f808146a000+d000] [ +0.000008] Code: da ff ff 85 c0 89 c1 78 57 48 8d 4d c8 ba 30 75 00 00 44 89 e6 4c 89 ff e8 8a d5 ff ff 85 c0 89 c1 78 3d 48 8b 45 c8 8b 7b 04 <8b> 70 04 89 fa 39 f7 41 89 f0 48 8b 7b 08 48 8b 70 08 49 0f 47 d0 [ +0.000225] VBoxDrvLinuxIOCtl: copy_to_user(0x7f803f1f8d90,,0x18); uCmd=0xc0305698! [ +0.000055] VBoxDrvLinuxIOCtl: copy_to_user(0x7f803f37ad90,,0x18); uCmd=0xc0305698!
comment:12 by , 5 years ago
Ok, this Virtualbox crash can be reproduced very easy and straight forward. I used the folloing config and steps:
Guest: Ubuntu 19.10 Host: Ubuntu 18.04.03 Virtualbox 6.1.2
1) start the guest VM
2) start libreoffice calc in the host
3) start libreoffice calc in the guest
4) write numbers and letters to different random cells in the hosts libreoffice calc spreadsheet
5) select those cells with content in the hosts libreoffice calc spreadsheet and select "copy" within the right click mouse menue
6) switch over to the guest window, with the mouse click into the empty open libreoffice calc spreadsheet in the guest, use the right click mouse menu and select "paste"
Now the guest VM dies along with the entire hosts Virtualbox instance with a core dump being written due a segfault in ShClipboard/VBoxSharedClipboard.so
comment:13 by , 5 years ago
Also happening on Fedora 31 host, Win10 guest, with following kernel log error:
Feb 19 10:44:17 ilan audit[17325]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=17325 comm="ShClipboard" exe="/usr/lib/virtual> Feb 19 10:44:17 ilan kernel: ShClipboard[17351]: segfault at 4 ip 00007fa18c02437b sp 00007fa1747b4d00 error 4 in VBoxSharedClipboard.so[7fa18c01d000+8000] Feb 19 10:44:17 ilan kernel: Code: 41 89 c4 85 c0 78 4d 48 8d 4d c8 ba 30 75 00 00 44 89 f6 4c 89 ff e8 44 cb ff ff 41 89 c4 85 c0 78 32 48 8b 45 c8 48 8b 7b 08 <8b> 50 04 39 53 04 0f 46 53> Feb 19 10:44:20 ilan kernel: vboxdrv: 000000009f13de31 VMMR0.r0 Feb 19 10:44:20 ilan kernel: vboxdrv: 000000008ce0363c VBoxDDR0.r0 Feb 19 10:44:20 ilan kernel: vboxdrv: 00000000f40f4e41 VBoxEhciR0.r0 Feb 19 10:44:20 ilan kernel: VMMR0InitVM: eflags=40246 fKernelFeatures=0x6 (SUPKERNELFEATURES_SMAP=1)
As others have said, I don't get any entries in the VM logs: the abort seems to be quite sudden: nothing in the log file at all when it happens.
VM guest randomly aborts even with larger amounts of text being copied/pasted (like 10KB or so). I've also had to disable shared clipboard.
comment:14 by , 5 years ago
Follow-up: Updated to 6.1.4-136177~Ubuntu~eoan, updated guest tools as well - Win10 x64 guest ran quite stable for a few hours, then segfault again. It's definitely been better than before, but still...
Feb 21 12:34:26 edbook kernel: [ 7824.071039] ShClipboard[15574]: segfault at 4 ip 00007fb720504ccc sp 00007fb709af6cf0 error 4 in VBoxSharedClipboard.so[7fb7204fd000+8000] Feb 21 12:34:26 edbook kernel: [ 7824.071064] Code: 89 c6 85 c0 78 52 48 8d 4d c0 ba 30 75 00 00 44 89 ee 4c 89 ff e8 04 c9 ff ff 41 89 c6 85 c0 78 37 4c 8b 45 c0 89 da 4c 89 e7 <41> 39 58 04 41 0f 46 50 04 4c 89 45 b8 49 8b 70 08 89 d2 e8 3c 8a
Back to disabling shared clipboard again, it is...
comment:15 by , 5 years ago
PLEASE READ ===
Please, please no more adding of the same error message over and over and over again, unless you have something to contribute to this bug technically or by describing a method to reproduce this bug in a simple fashion, please abstain from posting yet another error message that you saw. We all know by now. Please do not clutter the bug anymore. Thanks
comment:16 by , 5 years ago
So using a debug trunk version of Virtualbox we finally get a reasonable core dump and stacktrace to start with:
2020-02-24T15:33:15.089627+01:00 hpbox kernel: [ 8585.438176] ShClipboard[29578]: segfault at 4 ip 00007fa0040c6459 sp 00007fa00414cd00 error 4 in VBoxSharedClipboard.so[7fa0040bf000+8000] 2020-02-24T16:07:49.701647+01:00 hpbox kernel: [10660.049385] ShClipboard[30678]: segfault at 4 ip 00007ff5e1678459 sp 00007ff5e16fed00 error 4 in VBoxSharedClipboard.so[7ff5e1671000+8000]
hpbox:/var/cores # gdb core.ShClipboard.30645
GNU gdb (GDB; openSUSE Tumbleweed) 8.3.1
[...]
eading symbols from /usr/lib/virtualbox/VirtualBoxVM...
Reading symbols from /usr/lib/debug/usr/lib/virtualbox/VirtualBoxVM-6.1.3_openSUSETW-1.x86_64.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib/virtualbox/VirtualBoxVM --comment Ubtunu19.10 --startvm 6ab7a87e-6588-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ff5e1678459 in ShClSvcImplReadData (pClient=pClient@entry=0x7ff5dc009810, pCmdCtx=pCmdCtx@entry=0x7ff5e16fed98,
uFormat=2, pvData=0x7ff5cc3b3de0, cbData=cbData@entry=4096, pcbActual=pcbActual@entry=0x7ff5e16fed94)
at /site/ws/vbtrunk/trunk/src/VBox/HostServices/SharedClipboard/VBoxSharedClipboardSvc-x11.cpp:209
209 memcpy(pvData, pPayload->pvData, RT_MIN(cbData, pPayload->cbData));
[Current thread is 1 (Thread 0x7ff5e16ff700 (LWP 30678))]
[...]
(gdb) bt
#0 0x00007ff5e1678459 in ShClSvcImplReadData (pClient=pClient@entry=0x7ff5dc009810, pCmdCtx=pCmdCtx@entry=0x7ff5e16fed98,
uFormat=2, pvData=0x7ff5cc3b3de0, cbData=cbData@entry=4096, pcbActual=pcbActual@entry=0x7ff5e16fed94)
at /site/ws/vbtrunk/trunk/src/VBox/HostServices/SharedClipboard/VBoxSharedClipboardSvc-x11.cpp:209
#1 0x00007ff5e1673c3f in shClSvcClientReadData (paParms=0x7ff58b69f760, cParms=3, pClient=0x7ff5dc009810)
at /site/ws/vbtrunk/trunk/src/VBox/HostServices/SharedClipboard/VBoxSharedClipboardSvc.cpp:1606
#2 svcCall (callHandle=0x7ff5cc3b3c60, u32ClientID=<optimized out>, pvClient=0x7ff5dc009810, u32Function=<optimized out>,
cParms=3, paParms=0x7ff58b69f760, tsArrival=14087018054715)
at /site/ws/vbtrunk/trunk/src/VBox/HostServices/SharedClipboard/VBoxSharedClipboardSvc.cpp:1978
#3 0x00007ff609a5710e in hgcmServiceThread (pThread=0x7ff5dc001600, pvUser=0x7ff5dc0014a0)
at /site/ws/vbtrunk/trunk/src/VBox/Main/src-client/HGCM.cpp:662
#4 0x00007ff609a551af in hgcmWorkerThreadFunc (hThreadSelf=<optimized out>, pvUser=0x7ff5dc001600)
at /site/ws/vbtrunk/trunk/src/VBox/Main/src-client/HGCMThread.cpp:200
#5 0x00007ff61eac5414 in rtThreadMain (pThread=pThread@entry=0x7ff5dc001830, NativeThread=NativeThread@entry=140694025926400,
pszThreadName=pszThreadName@entry=0x7ff5dc002110 "ShClipboard")
at /site/ws/vbtrunk/trunk/src/VBox/Runtime/common/misc/thread.cpp:725
#6 0x00007ff61eb7c60e in rtThreadNativeMain (pvArgs=0x7ff5dc001830)
at /site/ws/vbtrunk/trunk/src/VBox/Runtime/r3/posix/thread-posix.cpp:362
#7 0x00007ff61ee5fefa in start_thread () from /lib64/libpthread.so.0
#8 0x00007ff61ed8b3bf in clone () from /lib64/libc.so.6
This corresponds to the following code in
trunk/src/VBox/HostServices/SharedClipboard/VBoxSharedClipboardSvc-x11.cpp
178 int ShClSvcImplReadData(PSHCLCLIENT pClient,
179 PSHCLCLIENTCMDCTX pCmdCtx, SHCLFORMAT uFormat, void *pvData, uint32_t cbData, uint32_t *pcbActual)
180 {
181 AssertPtrReturn(pClient, VERR_INVALID_POINTER);
182 AssertPtrReturn(pCmdCtx, VERR_INVALID_POINTER);
183 AssertPtrReturn(pvData, VERR_INVALID_POINTER);
184
185 RT_NOREF(pCmdCtx);
186
187 LogFlowFunc(("pClient=%p, uFormat=%02X, pv=%p, cb=%u, pcbActual=%p\n",
188 pClient, uFormat, pvData, cbData, pcbActual));
189
190 int rc = VINF_SUCCESS;
191
192 CLIPREADCBREQ *pReq = (CLIPREADCBREQ *)RTMemAllocZ(sizeof(CLIPREADCBREQ));
193 if (pReq)
194 {
195 pReq->pv = pvData;
196 pReq->cb = cbData;
197 pReq->pcbActual = pcbActual;
198 const SHCLEVENTID idEvent = ShClEventIdGenerateAndRegister(&pClient->EventSrc);
199 pReq->idEvent = idEvent;
200 if (idEvent != NIL_SHCLEVENTID)
201 {
202 rc = ShClX11ReadDataFromX11(&pClient->State.pCtx->X11, uFormat, pReq);
203 if (RT_SUCCESS(rc))
204 {
205 PSHCLEVENTPAYLOAD pPayload;
206 rc = ShClEventWait(&pClient->EventSrc, idEvent, 30 * 1000, &pPayload);
207 if (RT_SUCCESS(rc))
208 {
209 memcpy(pvData, pPayload->pvData, RT_MIN(cbData, pPayload->cbData));
follow-up: 21 comment:17 by , 5 years ago
I reproduce the segfault when trying to paste into guest with clipboard cleared by KeePass (Paste menu item is disabled in gnome-terminal on host for example) - I recommend to check NULL checks.
comment:18 by , 5 years ago
I have the same issue with Win10 guest on 6.1.4 #19471, I've able to get core dump but but I have no debug symbols to investigate any further. Where did you get debug trunk have you build it yourself?
follow-up: 20 comment:19 by , 5 years ago
| Status: | new → awaitsfeedback |
|---|
I Have the same issue on Windows and Ubuntu hosts on 6.1.6 Log : Apr 15 12:10:18 kernel: [ 8701.481110] ShClipboard[6666]: segfault at 4 ip 00007fbf1c00bcdc sp 00007fbef9274cf0 error 4 in VBoxSharedClipboard.so[7fbf1c004000+8000]
comment:20 by , 5 years ago
| Status: | awaitsfeedback → new |
|---|
Replying to Kévin Leroy:
I Have the same issue on Windows and Ubuntu hosts on 6.1.6 Log : Apr 15 12:10:18 kernel: [ 8701.481110] ShClipboard[6666]: segfault at 4 ip 00007fbf1c00bcdc sp 00007fbef9274cf0 error 4 in VBoxSharedClipboard.so[7fbf1c004000+8000]
follow-up: 22 comment:21 by , 5 years ago
Replying to Jan Kalina:
I reproduce the segfault when trying to paste into guest with clipboard cleared by KeePass (Paste menu item is disabled in gnome-terminal on host for example) - I recommend to check NULL checks.
This is indeed a good observation - after I read your comment, it became clear to me that the issue (reproducible) only happens to me when my clipboard is empty. KeePass is one reason for this, but there are other possibilities as well. The KDE Plasma clipboard widget does this under certain circumstances methinks.
A temporary workaround on KDE Plasma is to check the "Prevent empty clipboard" option in the widget settings. This makes it fairly stable to me. (Had one or two VirtualBox segfaults, maybe the widget wasn't quick enough to fill the clipboard with the most recent history entry.)
comment:22 by , 5 years ago
Replying to EdRoxter:
A temporary workaround on KDE Plasma is to check the "Prevent empty clipboard" option in the widget settings. This makes it fairly stable to me. (Had one or two VirtualBox segfaults, maybe the widget wasn't quick enough to fill the clipboard with the most recent history entry.)
I have that checked and still crashes easily and the clipboard isn't empty. The other remaining factor is that I was try to copying some text in KRDC RDP Session, Virtualbox was inactive in the background
comment:23 by , 5 years ago
I have >1-2 VM aborts per day currently, with 6.1.8 on ubuntu 19.10
Both windows10/1909 and ubuntu 20.04 guests are affected similarly.
Frequently it seems that they silently abort whilst not in use, so I have struggled to identify the causes.
However, following a forumpost I pulled out 2x key events in syslog: May 22 09:35:14 myhost kernel: [152617.148444] ShClipboard[30667]: segfault at 4 ip 00007efde0027cdc sp 00007efdc3efdcf0 error 4 in VBoxSharedClipboard.so[7efde0020000+8000] May 22 09:35:14 myhost kernel: [152617.148457] Code: 89 c6 85 c0 78 52 48 8d 4d c0 ba 30 75 00 00 44 89 ee 4c 89 ff e8 e4 c8 ff ff 41 89 c6 85 c0 78 37 4c 8b 45 c0 89 da 4c 89 e7 <41> 39 58 04 41 0f 46 50 04 4c 89 45 b8 49 8b 70 08 89 d2 e8 2c 8a
May 22 14:40:03 myhost kernel: [170906.135480] ShClipboard[2959]: segfault at 4 ip 00007f041846ecdc sp 00007f04184f4cf0 error 4 in VBoxSharedClipboard.so[7f0418467000+8000] May 22 14:40:03 myhost kernel: [170906.135493] Code: 89 c6 85 c0 78 52 48 8d 4d c0 ba 30 75 00 00 44 89 ee 4c 89 ff e8 e4 c8 ff ff 41 89 c6 85 c0 78 37 4c 8b 45 c0 89 da 4c 89 e7 <41> 39 58 04 41 0f 46 50 04 4c 89 45 b8 49 8b 70 08 89 d2 e8 2c 8a
Both hosts have bidrectional clipboard sharing & are usually running simultaneously.
Since it's often been the guest I'm not using that aborts, I can't pin down whether it is activity on the host or the other guest that prompts the issue.
Sometimes it seems to have occurred whilst the machines are idle/locked overnight, so it may not be entirely user activity.
I am leaving clipboard sharing disabled on both guests for now to see whether than improves stability.
comment:24 by , 4 years ago
Predictably, with the clipboard disabled everything is more stable. I have been enabling/disabling the clipboard as required.
Just now though, I forgot to disable the clipboard.
And I had a clipboard segfault.... ....but the machine that aborted was a linux machine with the clipboard disabled.
May 28 17:00:40 myhost kernel: [ 9370.330000] ShClipboard[4842]: segfault at 4 ip 00007f44a4030cdc sp 00007f448d1f7cf0 error 4 in VBoxSharedClipboard.so[7f44a4029000+8000] May 28 17:00:40 myhost kernel: [ 9370.330009] Code: 89 c6 85 c0 78 52 48 8d 4d c0 ba 30 75 00 00 44 89 ee 4c 89 ff e8 e4 c8 ff ff 41 89 c6 85 c0 78 37 4c 8b 45 c0 89 da 4c 89 e7 <41> 39 58 04 41 0f 46 50 04 4c 89 45 b8 49 8b 70 08 89 d2 e8 2c 8a
comment:25 by , 4 years ago
I have similar issue on version 6.1.6. It runs on Linux host (Ubuntu 20.04), and Windows 10 runs as guest. It doesn't happen very often, but it happens from time to time, and also if I don't do do anything in the guest machine.
comment:26 by , 4 years ago
I can confirm this behavior. My VM was crashing on and off (VB 6.x). Today my VM was crashing as soon as I open Netbeans. As suggested by @simonc, disabled clipboard and opened Netbeans IDE, no issue. Then I quit Netbeans, enabled clipboard and started Netbeans again, VM crashed immediately.
comment:28 by , 4 years ago
I see this behavior in a Windows 10 guest on Oracle Linux 8.2 host with VirtualBox 6.1.10. I have two Windows virtual machines running most of the time and this just started happening today - twice. I had bidirectional shared clipboard enabled.
comment:29 by , 4 years ago
I can confirm the problem also with Windows 10 Guest on Linux Debian 10 Host too in the VirtualBox 6.1.12, this version crashes even more often than 6.1.10, I had to downgrade to 6.1.10. If the guest additions are not installed, in the guest, the problem seems to disappear for me...
comment:31 by , 4 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:32 by , 4 years ago
I think I found and fixed the issue.
Can you please try with the latest test build for VirtualBox 6.1? You can get the latest test builds on the Testbuilds page.
Please note that also the Guest Additions of this test build need to be installed on the guest, followed by a guest reboot.
Let me know if this fixes the issue for you. Thank you!
comment:33 by , 4 years ago
Hi pentagonik,
YOU ARE THE MAN! I used 6.1.12 and was affected terribly by this crash. Just used Testbuilds 6.1.13 and bidirectional clipboard is working without problems, thanks a lot.
My config: Ubuntu 20.04 host, Windows 7 Pro guest, Windows XP guest
comment:35 by , 4 years ago
Hi, thanks for the fix - I have been using 6.1.13.139930 on ubuntu20.04, with win10 guest & guest additions.
Works very well, no unexpected segfaults over several days - all good.
cheers
by , 4 years ago
| Attachment: | coredumpctl_info.txt added |
|---|
output of coredump tool on crashed VirtualBox process
comment:36 by , 4 years ago
VirtualBox 6.1.13 r140058 (Qt5.6.1).
I'm still getting crashes even shared clipboard is disabled in the guest, now whole Xorg wen't down and because it whole bunch of guests, too. I don't remember if it did this earlier. VirtualBox 6.1.97 r139475 (Qt5.6.1) was stable with shared clipboard disabled, of course.
[Aug28 13:28] SHCLX11[2323506]: segfault at 75d73090 ip 00007fa482559d86 sp 00007fa4480ec940 error 4 in libc-2.32.so[7fa482540000+14d000] [ +0.003398] Code: ff 4c 8b 2d fc 4b 18 00 4d 89 4f 08 64 8b 04 25 18 00 00 00 85 c0 0f 85 a8 00 00 00 41 83 2e 01 4c 89 c8 48 c1 e0 05 4c 01 f8 <48> 8b 50 10 48 83 fa 03 74 30 48 83 fa 04 75 8a 48 8b 50 18 48 8b
comment:37 by , 4 years ago
@hotjava1231 Could you please provide the full core dump (zippped) so we can take a look? The attached text file does not contain enough information unfortunately.
follow-up: 41 comment:38 by , 4 years ago
@hotjava1231 Also, can you tell if this is reproducible for you, and if so, how to exactly reproduce the issue?
comment:39 by , 4 years ago
I have been experiencing this bug so often that I was literally in the process of moving off of VirtualBox. I could not go more than a couple hours with a crash. After installing the 6.1.13 test build, I have not had a single crash in three days. I believe this fix really does address the issue. I think this is a very critical issue, and am looking forward to it hitting mainstream. Thank you so much.
comment:40 by , 4 years ago
I've had a few instances now where copying/pasting to/from the host has caused 1 or more of the following: 1) Virtualbox freezes, host declares Wait|force Quit, 2) chromium window on the host being pasted into crashes. When this crashes the guest resumes operation. Seems to be application dependent on the guest, eg, copying text from browser to windows powershell window or from command window to host VSCode. Most copy/paste operations to/from host are fine though. I have not had a vbox crash that I could directly associate with this though.
comment:41 by , 4 years ago
Replying to pentagonik:
@hotjava1231 Could you please provide the full core dump (zippped) so we can take a look? The attached text file does not contain enough information unfortunately.
I'm sorry but due to sensitive stuff I was doing back then, I can't provide the core dump. However if you could provide to me a build of VirtualBox which includes the debug info et al, I might get more info about this peculiar bug.
Replying to pentagonik:
@hotjava1231 Also, can you tell if this is reproducible for you, and if so, how to exactly reproduce the issue?
Hmm, I'm not sure now if I can reproduce this issue correctly or if it did have something to do with VirtualBox. I have few LXC containers which shares Xorg resources with the host and one of them, 32-bit Arch Linux container had a bad pango package installed which caused certain applications to hang whole host Xorg. Only killing hang application via different virtual terminal brought Xorg back to life. I did run these applications few times to determine the root cause (which was the pango package) and during these test, Xorg server in the host went down.
comment:42 by , 4 years ago
I've crashed WinXP guest on VB 6.1.14
Copy pasted url from guest firefox to host firefox. Symptoms: on guest, it wasn't possible to copy paste between processed, the clipboard was completely broken inside the guest. When pasted to host, firefox freezes for few seconds and then didn't paste anything. I've restarted the VBoxTray.exe on the guest and when I played with it the guest crashed. Here is what was left in the VBox.log file:
21:55:42.065945 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 21:56:12.066999 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 21:56:12.067025 Shared Clipboard: Converting X11 format 'text/plain;charset=utf-8' (idxFmtX11=3) to VBox format 0x1 failed, rc=VERR_NO_DATA 21:56:42.067797 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 21:56:42.067824 Shared Clipboard: Converting X11 format 'text/plain;charset=utf-8' (idxFmtX11=3) to VBox format 0x1 failed, rc=VERR_NO_DATA 21:57:12.068377 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 21:57:12.068507 Shared Clipboard: Converting VBox formats 0x1 to 'INVALID' for X11 (idxFmtX11=0, fmtX11=0) failed, rc=VERR_NOT_SUPPORTED 21:57:42.068842 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 21:57:42.068875 Shared Clipboard: Converting X11 format 'text/plain;charset=utf-8' (idxFmtX11=3) to VBox format 0x1 failed, rc=VERR_NO_DATA
I am now running the guest with crash dump collecting command line. If it will crash again I will post more info.
comment:43 by , 4 years ago
I've reproduced the crash mentioned above and here is the stacktrace. I don't have symbols for VB binaries.
#0 tcache_get (tc_idx=<optimized out>) at malloc.c:2937
#1 __GI___libc_malloc (bytes=36) at malloc.c:3051
#2 0x00007f0da15db0c6 in read_packet (c=0x7f0d34008330) at ../../src/xcb_in.c:259
#3 _xcb_in_read (c=c@entry=0x7f0d34008330) at ../../src/xcb_in.c:1031
#4 0x00007f0da15d8e9f in _xcb_conn_wait (c=c@entry=0x7f0d34008330, cond=cond@entry=0x7f0d8c247b40, vector=vector@entry=0x0,
count=count@entry=0x0) at ../../src/xcb_conn.c:516
#5 0x00007f0da15da61f in wait_for_reply (c=c@entry=0x7f0d34008330, request=request@entry=87, e=e@entry=0x7f0d8c247c00)
at ../../src/xcb_in.c:516
#6 0x00007f0da15da796 in xcb_wait_for_reply64 (c=c@entry=0x7f0d34008330, request=87, e=e@entry=0x7f0d8c247c00) at ../../src/xcb_in.c:560
#7 0x00007f0da1446d38 in _XReply (dpy=dpy@entry=0x7f0d34005cc0, rep=rep@entry=0x7f0d8c247c50, extra=extra@entry=0,
discard=discard@entry=1) at ../../src/xcb_io.c:609
#8 0x00007f0da1442641 in XSync (dpy=dpy@entry=0x7f0d34005cc0, discard=discard@entry=1) at ../../src/Sync.c:44
#9 0x00007f0da142336f in XCloseDisplay (dpy=dpy@entry=0x7f0d34005cc0) at ../../src/ClDisplay.c:61
#10 0x00007f0d4fdb53ad in CloseDisplay (dpy=dpy@entry=0x7f0d34005cc0) at ../../src/Display.c:664
#11 0x00007f0d4fdb5fda in XtCloseDisplay (dpy=0x7f0d34005cc0) at ../../src/Display.c:680
#12 0x00007f0d4fdb6069 in DestroyAppContext (app=app@entry=0x7f0d34004120) at ../../src/Display.c:463
#13 0x00007f0d4fdb61fc in XtDestroyApplicationContext (app=0x7f0d34004120) at ../../src/Display.c:502
#14 0x00007f0d944b8d01 in ?? () from /usr/lib/virtualbox/VBoxSharedClipboard.so
#15 0x00007f0d944bad01 in ?? () from /usr/lib/virtualbox/VBoxSharedClipboard.so
#16 0x00007f0d944bafbc in ?? () from /usr/lib/virtualbox/VBoxSharedClipboard.so
#17 0x00007f0d944b4da9 in ?? () from /usr/lib/virtualbox/VBoxSharedClipboard.so
#18 0x00007f0d94b0f87d in ?? () from /usr/lib/virtualbox/components/VBoxC.so
#19 0x00007f0d94b0d793 in ?? () from /usr/lib/virtualbox/components/VBoxC.so
#20 0x00007f0da61791b8 in ?? () from /usr/lib/virtualbox/VBoxRT.so
#21 0x00007f0da623c6b2 in ?? () from /usr/lib/virtualbox/VBoxRT.so
#22 0x00007f0da6550609 in start_thread (arg=<optimized out>) at pthread_create.c:477
What is it? Memory corruption? How is it managed to crash malloc?
comment:44 by , 4 years ago
It is actually rather easy to reproduce on WinXP guest and probably on the other guests too. Create a file c:\Program Files\Oracle\VirtualBox Guest Additions\restart.bat
taskkill /f /t /im VBoxTray.exe start VBoxTray.exe
Open a chrome or firefox browser inside the guest and on the host. And start copying url from the guest browser to the host and hit this bat file, copy and hit, hit and copy in a random order, after like 10 repetitions it will crash the guest VM process.
I've created this bat file to fix freezes and broken copy paste in the past. I've thought that this is a bug in an outdated legacy winxp guest additions, but it is crashing the process on the host so it is definitely a bug on the host (either Xorg or VB), it shouldn't crash whatever I do inside the guest.
comment:45 by , 4 years ago
Similar behaviour when I use VirtualBox Graphical User Interface Version 6.1.12_Gentoo r139365, run a KDE Neon under Sabayon Linux:
Operating System: Gentoo Linux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.0 Kernel Version: 5.7.0-sabayon OS Type: 64-bit Processors: 8 × Intel® Core™ i7 CPU 920 @ 2.67GHz Memory: 23,5 GiB of RAM Graphics Processor: GeForce GTX 1060 6GB/PCIe/SSE2
Mainly, happens when I connect remotely to other machine (not the hosted one) using KRDC.
I presume the crash occurs when the clipboard is accessed by one of them, VirtualBox or KRDC. Could it be a resource lock problem.
In my logs:
[85431.776497] ShClipboard[15972]: segfault at 4 ip 00007ff2f9cc84e2 sp 00007ff2dfafbcf0 error 4 in VBoxSharedClipboard.so[7ff2f9cc1000+8000]
comment:46 by , 4 years ago
Thanks for the additional information -- I'll have another peek at this in a short while.
follow-up: 48 comment:47 by , 4 years ago
@----------: Please note that 6.1.12 did not have the fix in the place I wrote about in comment 32. You need to use VBox 6.1.14 (plus 6.1.14 Guest Additions).
@GnomeUser: Did you also install the 6.1.14 Guest Additions inside the guest,followed by a guest reboot?
comment:48 by , 4 years ago
@pentagonik yes everything is updated to the most recent 6.1.14.40239 version. Actually your question doesn't make sense because the host process is crashing. It doesn't matter what guest addition is running on the client, no action inside the guest should cause crashes on the host.
comment:49 by , 4 years ago
I can confirm issue still exists:
00:14:03.771458 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT
Causing a long timeout but not on the VM but on the Host itself. In my case it will abort eventually, but only after multiple tries. However, instead of a segfault it looks like a conversion issue instead. Also I do not have the issue everytime, so I can not really put my finger on it.
I am running Pop OS 20.04, Kernel 5.8.10, AMD Ryzen 7 4750u
comment:50 by , 4 years ago
@GnomeUser That is true, but more information helps isolating the problem. What kind of data inside the guest/host browsers are you copying to the clipboard? Are you able to provide us a core dump of crashed VM process so that we can have a look at it?
So far I'm not able to getting a crash reproduced on the host side.
comment:52 by , 4 years ago
@pentagonik have you tried to restart the guest addition VBoxTray.exe and copy paste multiple times as I describe in comment #44?
comment:53 by , 4 years ago
Yes, I did so ... I think I now reproduced it finally one single time, not really knowing how to exactly getting this reproduced. Let's see if I can work with my debug backtrace.
comment:54 by , 4 years ago
@GnomeUser Do see something like "Shared Clipboard: Stopping X11 event thread failed [...]" in your log before it crashes?
comment:55 by , 4 years ago
@pentagonik yes, but not exactly
10:02:09.646363 Shared Clipboard: Stopping X11 event thread ... 10:02:09.646398 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 10:02:09.646416 Shared Clipboard: Converting X11 format 'UTF8_STRING' (idxFmtX11=1) to VBox format 0x1 failed, rc=VERR_NO_DATA 10:02:09.646461 Shared Clipboard: X11 event thread terminated successfully
And it crashes in tcache_get and _GI_libc_malloc every time
comment:56 by , 4 years ago
Thanks for the additional information.
I think I found and fixed the problem -- will upload a new 6.1 testbuild shortly so that you also can have a try.
comment:57 by , 4 years ago
The new 6.1 testbuild (141063) is now available here.
Guest Additions don't need to be updated.
Please let me know if this now works for you. Thanks!
comment:58 by , 4 years ago
Ok, it is now harder to crash, but I've still crashed it following the above procedure. The stacktrace is different this time
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fb9af322859 in __GI_abort () at abort.c:79
#2 0x00007fb9af38d3ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fb9af4b7285 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007fb9af39547c in malloc_printerr (str=str@entry=0x7fb9af4b9ad8 "malloc(): unsorted double linked list corrupted") at malloc.c:5347
#4 0x00007fb9af39846c in _int_malloc (av=av@entry=0x7fb950000020, bytes=bytes@entry=208) at malloc.c:3744
#5 0x00007fb9af39a419 in __GI___libc_malloc (bytes=bytes@entry=208) at malloc.c:3066
#6 0x00007fb9accdb38f in _XEnq (dpy=dpy@entry=0x7fb9500059a0, event=event@entry=0x7fb950005130) at ../../src/XlibInt.c:751
#7 0x00007fb9accd7f07 in handle_response (dpy=dpy@entry=0x7fb9500059a0, response=0x7fb950005130, in_XReply=in_XReply@entry=1)
at ../../src/xcb_io.c:338
#8 0x00007fb9accd8e6d in _XReply (dpy=dpy@entry=0x7fb9500059a0, rep=rep@entry=0x7fb96d94bc50, extra=extra@entry=0,
discard=discard@entry=1) at ../../src/xcb_io.c:634
#9 0x00007fb9accd4641 in XSync (dpy=dpy@entry=0x7fb9500059a0, discard=discard@entry=1) at ../../src/Sync.c:44
#10 0x00007fb9accb536f in XCloseDisplay (dpy=dpy@entry=0x7fb9500059a0) at ../../src/ClDisplay.c:61
#11 0x00007fb96d4723ad in CloseDisplay (dpy=dpy@entry=0x7fb9500059a0) at ../../src/Display.c:664
#12 0x00007fb96d472fda in XtCloseDisplay (dpy=0x7fb9500059a0) at ../../src/Display.c:680
#13 0x00007fb96d473069 in DestroyAppContext (app=app@entry=0x7fb950003e00) at ../../src/Display.c:463
#14 0x00007fb96d4731fc in XtDestroyApplicationContext (app=0x7fb950003e00) at ../../src/Display.c:502
#15 0x00007fb96d6c5b3f in ?? () from /opt/VirtualBox/VBoxSharedClipboard.so
#16 0x00007fb96d6c5c4a in ?? () from /opt/VirtualBox/VBoxSharedClipboard.so
#17 0x00007fb96d6c690b in ?? () from /opt/VirtualBox/VBoxSharedClipboard.so
#18 0x00007fb96d6c0664 in ?? () from /opt/VirtualBox/VBoxSharedClipboard.so
#19 0x00007fb992d2b882 in ?? () from /opt/VirtualBox/components/VBoxC.so
#20 0x00007fb992d28308 in ?? () from /opt/VirtualBox/components/VBoxC.so
#21 0x00007fb9aea38fac in ?? () from /opt/VirtualBox/VBoxRT.so
#22 0x00007fb9aeaf2c71 in ?? () from /opt/VirtualBox/VBoxRT.so
#23 0x00007fb9af6df609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#24 0x00007fb9af41f293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
VBox.log is ending with these lines
Shared Clipboard: Stopping X11 event thread ... Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT Shared Clipboard: Converting X11 format 'text/plain;charset=utf-8' (idxFmtX11=3) to VBox format 0x1 failed, rc=VERR_NO_DATA Shared Clipboard: X11 event thread terminated successfully
Side note, it becomes basically unusable on WinXP guest, every second copy&paste trigger this error "Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT".
comment:59 by , 4 years ago
I've just uploaded a new 6.1 testbuild 141128 with new fixes, in the hope that this now improves the situation for you. Please let me know the results -- thanks!
comment:60 by , 4 years ago
I am not able to crash it now. But the error
Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT
is still happening periodically. Was it the cause of crashes or just a coincidence? I've also noted that the same time this line appears in the \var\log\syslog
gnome-shell: Failed to store clipboard: Format UTF8_STRING not supported
But at least it doesn't crash now.
comment:61 by , 4 years ago
@pentagonik this testbuild is hanging after some period of time and it happens without any copypaste operation. The VM remains operational, it can be pinged and terminated through ACPI shutdown but the hanging window still stays open even after shutdown. The 6.1.16 release is working fine. I am not sure what this testbuild number 141128 stands for, is it a revision number in a master branch or is it a special testbuild that only includes your patch, Virtualbox is opensource but its development is concealed so I am not sure where to report this.
comment:62 by , 4 years ago
I've tried the testbuild version, still had the issue. I now switched back to 6.1.16 and still have the same issue. These are the logs:
01:15:34.204356 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 01:16:04.205040 Shared Clipboard: Converting VBox formats 0x1 to 'STRING' for X11 (idxFmtX11=4, fmtX11=2) failed, rc=VERR_TIMEOUT 01:16:34.205423 Shared Clipboard: Converting VBox formats 0x1 to 'STRING' for X11 (idxFmtX11=4, fmtX11=2) failed, rc=VERR_TIMEOUT 01:17:04.205675 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 01:17:34.206031 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 01:17:34.206379 Shared Clipboard: Converting VBox formats 0x1 to 'INVALID' for X11 (idxFmtX11=0, fmtX11=0) failed, rc=VERR_NOT_SUPPORTED 01:17:34.206728 Shared Clipboard: Converting VBox formats 0x1 to 'INVALID' for X11 (idxFmtX11=0, fmtX11=0) failed, rc=VERR_NOT_SUPPORTED 01:18:04.207132 Shared Clipboard: Converting VBox formats 0x1 to 'STRING' for X11 (idxFmtX11=4, fmtX11=2) failed, rc=VERR_TIMEOUT 01:18:34.207671 Shared Clipboard: Converting VBox formats 0x1 to 'STRING' for X11 (idxFmtX11=4, fmtX11=2) failed, rc=VERR_TIMEOUT 01:19:04.208789 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 01:19:34.209753 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 (idxFmtX11=3, fmtX11=3) failed, rc=VERR_TIMEOUT 01:20:04.210166 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 01:20:34.210574 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 01:20:34.210896 Shared Clipboard: Converting VBox formats 0x1 to 'INVALID' for X11 (idxFmtX11=0, fmtX11=0) failed, rc=VERR_NOT_SUPPORTED 01:20:34.211200 Shared Clipboard: Converting VBox formats 0x1 to 'INVALID' for X11 (idxFmtX11=0, fmtX11=0) failed, rc=VERR_NOT_SUPPORTED 01:21:04.211518 Shared Clipboard: Converting VBox formats 0x1 to 'STRING' for X11 (idxFmtX11=4, fmtX11=2) failed, rc=VERR_TIMEOUT 01:21:34.212019 Shared Clipboard: Converting VBox formats 0x1 to 'STRING' for X11 (idxFmtX11=4, fmtX11=2) failed, rc=VERR_TIMEOUT
When my VM stops, it does not generate an explicit error. Also, the issue I experience is the other way around: My VM keeps on running at first, but the application where I try to past text from the VM in get unresponsive (firefox) or I have to manually kill (slack) and start them again.
After a while my VM will stop working as well and abort.
It does work fine at first, issues will start around 30/60 minutes and then get worse and worse until the VM aborts. After starting the VM everyting works fine again. In a normal day I have around 2/3 crashes (9 hours of usage), so average 3 hours a workable.
follow-up: 66 comment:63 by , 4 years ago
@Borrelworst Can you please have a look at this page to enable verbose logging, also for the guest component (VBoxClient)?
Also, just for my understanding, you copy text from the host to guest, right? The more information we have about this issue, the faster we can solve this. Thanks!
comment:64 by , 4 years ago
For me it is now always guest->host with a paste of something that is more complex than a string.
Yes: A copy of text from VSCode in Win10 guest, pasted to VSCode in linux host works
No: Right click and copy a web link from an outlook2013 email & paste to chrome causes the chrome page to hang [and eventually chrome notifies of the failure]
Yes: On host, copy of google sheet cell, in win10 guest, paste into notepad [goes as text value]
Sort of: Same google sheet cell, in win10 guest, paste into excel : notification that excel cannot paste the data.
Similarly, copy of an excel2013 cell and paste into google sheets works fine within the host, but causes the chrome browser window to hang in the host.
The behaviour of the paste target crashing the host seems consistent regardless of target application type but if I'm careful to ensure the copy is of text it is reliable.
I concluded it was an issue to do with more complex source objects being copied.
I will take a look at turning on the X11 logging.
Ubuntu20.04 host, VBOX6.1.16+extensions, win10.19041 guest with 6.1.16 guest additions
comment:65 by , 4 years ago
@pentagonik I've tried to run it with VBOX_RELEASE_LOG=+shared_clipboard.e.l.f and all it gives is this additional line to the logfile:
Shared Clipboard: Guest writes 164 bytes clipboard data in format 1 to host
with no actual data it won't probably help diagnosing VERR_TIMEOUT.
Testbuild aren't crash (which is the subject of this issue) but its virtual machine window hangs after few hours of work leaving the VM running and fully functional under the frozen GUI.
comment:66 by , 4 years ago
Replying to pentagonik:
@Borrelworst Can you please have a look at this page to enable verbose logging, also for the guest component (VBoxClient)?
Also, just for my understanding, you copy text from the host to guest, right? The more information we have about this issue, the faster we can solve this. Thanks!
No, the weird thing is that it is the other way around: So copying text from guest to host, will generate hanging sessions on the host (firefox, gedit hangs, when copying from guest to slack, slack will completely hang and I have to kill it manually).
Copy from host to guest works fine most of the times, but after a while it just stops pasting my clipboard contents but will not result in hanging application in the guest itself.
I will enable verbose logging and see if I can generate some info on the issue. I do see however, that on the guest component the example is for Linux based system, but I run Linux host with a Windows guest. Any idea on how to enable verbose logging in windows?
follow-up: 71 comment:67 by , 4 years ago
Just registering my interest in this bug as I've been experiencing it since moving to VBox 6.X I'm currently on Version 6.1.16 r140961 (Qt5.6.1). My Host is OpenSUSE 15.1, my guest is Windows 10 Pro, Latest service Pack. All of the symptoms mentioned I've noticed at various times. If I use copy/paste without thinking, it's just a matter of time before the Windows guest will abort. The machine as a whole will go slow at times, but sometimes recover, only to eventually drop the VBOX guest. simple text copy/paste seems to work most of the time, but anything else seems to cause a problem. I'm happy to do testing and provide logs if asked specifically and my machine is available. It's my main development machine, so stability is a factor.
If I can provide anything else of use, please ask. Eric.
comment:68 by , 4 years ago
I'm still failing to getting this reproduced and still searching for a definitive use case which reproduced the behavior you mentioned.
No matter what I'm doing, I wasn't able to reproduce the freezes yet. I didn't try out Outlook, as I don't have this available.
It would help greatly if you could name one specific case with some freely available program from guest -> host to pinpoint the issue more quickly.
comment:69 by , 4 years ago
@pentagonik
There are three separate issues we discuss here:
1) segfaults and crashes on the 6.1.16. This is what this issue about and it seems to be fixed in 6.1.17.141128 testbuild. But more people should download the testbuild or the next VB version to test it.
2) a permanent freeze of the testbuild after few hours of work. I am not sure if it is relevant to this issue because it happens without any copy&paste operation. But it may be caused by your patches. The 6.1.16 didn't freeze like that. Does the testbuild only contain your patch and do not have any other current development changes? May be it is caused by changes in 3d acceleration driver or whatever. But it seems that I am the only one who downloaded the testbuild and other users here didn't face this bug. The guest doesn't crash and I can't give you the coredump. I can attach gdb to the running guest when this type of freeze happens in testbuild and give you the stacktraces of all the running threads if you want.
3) a temporal freeze with "formats 0x1 to 'UTF8_STRING'" and "VERR_TIMEOUT" in the log, mentioned by me, @Borrelworst, @simonc and everybody else. It doesn't cause guest to abort or crash on the 6.1.17.141128 testbuild. It is not a permanent freeze, it is just a slight delay (i.e. TIMEOUT) guest continue to run absolutely normal before and after it. This VERR_TIMEOUT was in the logs all the time, 6.1.16 and the testbuild. It seems that you didn't touch it by your patches. To reproduce I just run the WinXP guest, abuse it in some way (kill and run VBoxTray.exe etc) and then copy unicode string from guest to host.
People running the 6.1.16 observe (1) and (3), and confuse one with another. Me, running the 6.1.17.141128 testbuild observe (2) and (3). I hope this is sorted out by this comment.
I think you should try to run WinXP guest with installed guest additions on linux host (Ubuntu 20.04.1 X.org Gnome in my case) running 6.1.17.141128 testbuild, and leave it running in the background for 12 hours or so. You would observe either (2) or (3) freezes. If not then... well... I don't know, the (3) seems like a very easy reproducible bug and everyone here is mentioning it.
comment:70 by , 4 years ago
Thanks for the additional information. I've just uploaded a new 6.1 testbuild 141370, which also has some more additional Shared Clipboard logging (needs the verbose logging set, as posted above).
To your questions:
- The testbuilds generally contain the announced fixes in a ticket *and* all other fixes which might be backported to a certain version (e.g. 6.1). So it in theory could happen that changes went in which are responsible for those freezes.
- To rule out that the Shared Clipboard fixes are not causing this, it would be preferable if you could disable the Shared Clipboard functionality and repeat the test (e.g. running the VM for a few hours).
- The temporal freezes indeed are caused by the Shared Clipboard and are expected, at least for formats and/or quirks where it runs into a timeout.
- If you experiences the "real freezes" again, yes, please try attach GDB to the VM process and provide a backtrace if you can.
comment:71 by , 4 years ago
Replying to eacb:
Just registering my interest in this bug as I've been experiencing it since moving to VBox 6.X I'm currently on Version 6.1.16 r140961 (Qt5.6.1). My Host is OpenSUSE 15.1, my guest is Windows 10 Pro, Latest service Pack. All of the symptoms mentioned I've noticed at various times. If I use copy/paste without thinking, it's just a matter of time before the Windows guest will abort. The machine as a whole will go slow at times, but sometimes recover, only to eventually drop the VBOX guest. simple text copy/paste seems to work most of the time, but anything else seems to cause a problem. I'm happy to do testing and provide logs if asked specifically and my machine is available. It's my main development machine, so stability is a factor.
If I can provide anything else of use, please ask. Eric.
UPDATE: I was able to duplicate the exact same SYMPTOMS as discussed in this ticket, however it had nothing to do with copy/paste. This I have disabled. I was running on the Host (Linux Opensuse 15.2) a large build using gcc. Point being it was using a fair bit of processor. The Windows 10 guest starts to slow down and then the whole machine is virtually unusable until the point when the VBOX guest aborts and then the machine is okay again. I was not able to successfully bring up the guest and keep it up until I stopped the compiler build. It appears to be a load or race condition that is causing the issue. (Like VBox is not giving back resource when it should or something) I'm guessing the copy/paste function must cause a similar situation for some reason to produce the exact same symptoms. I'm unable to get to see what is chewing up CPU as the machine is unusable in this state. While I appreciate this anecdotal, this machine is always under very heavy load. I've only seen this problem since upgrading to VBox 6.X. If I don't push the machine to hard and don't use copy/paste it's been quite stable.
Eric.
comment:72 by , 4 years ago
I've checked the testbuild 141370.
1) it doesn't crash
2) permanent freezes still occur. I've tried to disable the shared clipboard and waited 9 hours during which it didn't freeze. Then I enabled it and it freeze 3-5 hours later. Then I've issued ACPI shutdown and when the VM exited I've attached gdb to the frozen window it left behind. This is the stacktrace of Thread 1. I have the stack trace of the other threads if you need.
Thread 1 (Thread 0x7f1ba8ee5740 (LWP 4976)): #0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7ffde2a964d8) at ../sysdeps/nptl/futex-internal.h:183 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x23bd398, cond=0x7ffde2a964b0) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x7ffde2a964b0, mutex=mutex@entry=0x23bd398) at pthread_cond_wait.c:638 #3 0x00007f1ba6bc2df0 in _xcb_conn_wait (c=c@entry=0x23bd380, cond=cond@entry=0x7ffde2a964b0, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:448 #4 0x00007f1ba6bc461f in wait_for_reply (c=c@entry=0x23bd380, request=7272344, e=e@entry=0x0) at ../../src/xcb_in.c:516 #5 0x00007f1ba6bc4735 in xcb_wait_for_reply (c=c@entry=0x23bd380, request=7272344, e=e@entry=0x0) at ../../src/xcb_in.c:532 #6 0x00007f1ba6bd5549 in xcb_xc_misc_get_xid_range_reply (c=c@entry=0x23bd380, cookie=..., e=e@entry=0x0) at xc_misc.c:137 #7 0x00007f1ba6bc5e58 in xcb_generate_id (c=0x23bd380) at ../../src/xcb_xid.c:63 #8 0x00007f1b9da8febc in ?? () from /opt/VirtualBox/libQt5XcbQpaVBox.so.5 #9 0x00007f1b9da8e80a in ?? () from /opt/VirtualBox/libQt5XcbQpaVBox.so.5 #10 0x00007f1b9da8fb0b in ?? () from /opt/VirtualBox/libQt5XcbQpaVBox.so.5 #11 0x00007f1b9ef56a8b in QWindowPrivate::setCursor(QCursor const*) () from /opt/VirtualBox/libQt5GuiVBox.so.5 #12 0x00007f1b9e73c84d in ?? () from /opt/VirtualBox/libQt5WidgetsVBox.so.5 #13 0x00007f1b9e73fa79 in QWidget::setCursor(QCursor const&) () from /opt/VirtualBox/libQt5WidgetsVBox.so.5 #14 0x00007f1ba6cb521b in ?? () from /opt/VirtualBox/VirtualBoxVM.so #15 0x00007f1b9f911442 in QMetaObject::activate(QObject*, int, int, void**) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #16 0x00007f1ba6cac683 in ?? () from /opt/VirtualBox/VirtualBoxVM.so #17 0x00007f1b9f911442 in QMetaObject::activate(QObject*, int, int, void**) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #18 0x00007f1b9f911442 in QMetaObject::activate(QObject*, int, int, void**) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #19 0x00007f1ba6d56b12 in ?? () from /opt/VirtualBox/VirtualBoxVM.so #20 0x00007f1b9f90f9a6 in QObject::event(QEvent*) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #21 0x00007f1b9e700454 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /opt/VirtualBox/libQt5WidgetsVBox.so.5 #22 0x00007f1b9e70598e in QApplication::notify(QObject*, QEvent*) () from /opt/VirtualBox/libQt5WidgetsVBox.so.5 #23 0x00007f1b9f8e2179 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #24 0x00007f1b9f8e5092 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #25 0x00007f1b9f936393 in ?? () from /opt/VirtualBox/libQt5CoreVBox.so.5 #26 0x00007f1b9e03afbd in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #27 0x00007f1b9e03b240 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x00007f1b9e03b2e3 in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x00007f1b9f935f0b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #30 0x00007f1b9f8e1063 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /opt/VirtualBox/libQt5CoreVBox.so.5 #31 0x00007f1b9f8e5702 in QCoreApplication::exec() () from /opt/VirtualBox/libQt5CoreVBox.so.5 #32 0x00007f1ba6c6f83e in TrustedMain () from /opt/VirtualBox/VirtualBoxVM.so #33 0x00007f1ba907b0b3 in __libc_start_main (main=0x401430, argc=3, argv=0x7ffde2a97e08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffde2a97df8) at ../csu/libc-start.c:308 #34 0x0000000000401369 in ?? () #35 0x00007ffde2a97df8 in ?? () #36 0x000000000000001c in ?? () #37 0x0000000000000003 in ?? () #38 0x00007ffde2a98299 in ?? () #39 0x00007ffde2a982b6 in ?? () #40 0x00007ffde2a982bf in ?? () #41 0x0000000000000000 in ?? ()
3) temporal freezes still occur and this is written to the log when I restarted the guest additions and copy pasted text from guest to host. This is the last 6 hours of the VM log. My attempts to reproduce temporal copy paste freezes and the permanent freeze and ACPI shutdown in the end:
09:11:50.402916 VMMDev: Guest Additions capability report: (0x4 -> 0x0) seamless: no, hostWindowMapping: no, graphics: no 09:11:50.403036 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners 09:11:50.403059 GUI: UIMachineLogicFullscreen: Additions-state actual-change event, rebuild multi-screen layout 09:11:50.403072 GUI: UIMultiScreenLayout::update: GUI/AutomountGuestScreens is disabled 09:11:50.403086 GUI: UIMachineViewFullscreen::adjustGuestScreenSize: Adjust guest-screen size if necessary. 09:11:50.403091 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 09:11:50.403114 Shared Clipboard: Signalling the X11 event thread to stop 09:11:50.403132 Shared Clipboard: Waiting for X11 event thread to stop ... 09:11:50.403319 Shared Clipboard: X11 event thread stopped successfully 09:11:50.446230 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners 09:11:50.446241 GUI: UIMachineLogicFullscreen: Additions-state actual-change event, rebuild multi-screen layout 09:11:50.446255 GUI: UIMultiScreenLayout::update: GUI/AutomountGuestScreens is disabled 09:11:50.446270 GUI: UIMachineViewFullscreen::adjustGuestScreenSize: Adjust guest-screen size if necessary. 09:11:50.446275 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 09:11:50.459226 VMMDev: Guest Log: RTLdrLoadAppPriv: "C:\Program Files\Oracle\VirtualBox Guest Additions\VBoxHook.dll" not found 09:11:50.459305 VMMDev: Guest Log: Starting services ... 09:11:50.459327 VMMDev: Guest Log: Starting service 'display' ... 09:11:50.459508 VMMDev: Guest Log: Service 'display' started 09:11:50.459529 VMMDev: Guest Log: Starting service 'clipboard' ... 09:11:50.459614 VMMDev: Guest Log: Shared Clipboard: New Clipboard API not available (VERR_SYMBOL_NOT_FOUND) 09:11:50.459691 Shared Clipboard: Starting X11 event thread ... 09:11:50.499989 Shared Clipboard: X11 event thread started 09:11:50.500017 Shared Clipboard: 0 formats were found 09:11:50.500026 Shared Clipboard: X11 reported available VBox formats: 0x0 09:11:50.503660 Shared Clipboard: Reporting formats 0x0 to guest 09:11:50.521689 VMMDev: Guest Log: Service 'clipboard' started 09:11:50.521726 VMMDev: Guest Log: Starting service 'seamless' ... 09:11:50.521799 VMMDev: Guest Log: RTLdrLoadAppPriv: "C:\Program Files\Oracle\VirtualBox Guest Additions\VBoxHook.dll" not found 09:11:50.521827 VMMDev: Guest Log: Seamless: Could not load VBoxHook.dll (VERR_FILE_NOT_FOUND), skipping 09:11:50.521844 VMMDev: Guest Log: Service 'seamless' is not supported on this system 09:11:50.521858 VMMDev: Guest Log: Starting service 'VRDP' ... 09:11:50.523165 VMMDev: Guest Log: Service 'VRDP' started 09:11:50.523194 VMMDev: Guest Log: Starting service 'IPC' ... 09:11:50.524377 VMMDev: Guest Log: VBoxIPCInit: Local IPC server now running at "\\.\pipe\VBoxTrayIPC-..." 09:11:50.524628 VMMDev: Guest Log: Service 'IPC' started 09:11:50.524650 VMMDev: Guest Log: Starting service 'LA' ... 09:11:50.524687 VMMDev: Guest Log: LA: RegQueryValueExW: failed [SOFTWARE\Oracle\VirtualBox Guest Additions/VBoxTrayLog] 09:11:50.524715 VMMDev: Guest Log: LA: RegQueryValueExW: failed [SOFTWARE\Oracle\VirtualBox Guest Additions/VBoxTrayLA] 09:11:50.524733 VMMDev: Guest Log: LA: DetachOnDisconnect=true 09:11:50.525135 VMMDev: Guest Log: Service 'LA' started 09:11:50.525154 VMMDev: Guest Log: Starting service 'draganddrop' ... 09:11:50.527986 VMMDev: Guest Log: DnD: Drag and drop service successfully started 09:11:50.528237 VMMDev: Guest Log: Service 'draganddrop' started 09:11:50.528258 VMMDev: Guest Log: All services started 09:11:50.628464 VMMDev: Guest Additions capability report: (0x0 -> 0x4) seamless: no, hostWindowMapping: no, graphics: yes 09:11:50.636268 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners 09:11:50.636303 GUI: UIMachineLogicFullscreen: Additions-state actual-change event, rebuild multi-screen layout 09:11:50.636317 GUI: UIMultiScreenLayout::update: GUI/AutomountGuestScreens is disabled 09:11:50.636332 GUI: UIMachineViewFullscreen::adjustGuestScreenSize: Adjust guest-screen size if necessary. 09:11:50.636337 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 09:11:50.636362 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 09:11:57.340484 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:11:57.340873 Shared Clipboard: Guest writes 86 bytes clipboard data in format 1 to host 09:12:02.160385 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 09:12:02.160630 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 09:12:05.441879 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:12:35.441991 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 09:12:35.443032 Shared Clipboard: Guest writes 86 bytes clipboard data in format 1 to host 09:12:35.444404 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:12:35.444695 Shared Clipboard: Guest writes 86 bytes clipboard data in format 1 to host 09:12:47.161477 Shared Clipboard: 14 formats were found 09:12:47.161500 Shared Clipboard: Found target 'TIMESTAMP' 09:12:47.161504 Shared Clipboard: Found target 'TARGETS' 09:12:47.161507 Shared Clipboard: Found target 'MULTIPLE' 09:12:47.161530 Shared Clipboard: Found target 'SAVE_TARGETS' 09:12:47.161550 Shared Clipboard: Found target 'text/html' 09:12:47.161569 Shared Clipboard: Found target 'text/_moz_htmlcontext' 09:12:47.161588 Shared Clipboard: Found target 'text/_moz_htmlinfo' 09:12:47.161592 Shared Clipboard: Found target 'UTF8_STRING' 09:12:47.161609 Shared Clipboard: Found target 'COMPOUND_TEXT' 09:12:47.161613 Shared Clipboard: Found target 'TEXT' 09:12:47.161615 Shared Clipboard: Found target 'STRING' 09:12:47.161628 Shared Clipboard: Found target 'text/plain;charset=utf-8' 09:12:47.161630 Shared Clipboard: Found target 'text/plain' 09:12:47.161650 Shared Clipboard: Found target 'text/x-moz-url-priv' 09:12:47.161723 Shared Clipboard: Reporting format 'text/html' 09:12:47.161729 Shared Clipboard: Reporting format 'UTF8_STRING' 09:12:47.161733 Shared Clipboard: Reporting format 'TEXT' 09:12:47.161735 Shared Clipboard: Reporting format 'STRING' 09:12:47.161738 Shared Clipboard: Reporting format 'text/plain;charset=utf-8' 09:12:47.161740 Shared Clipboard: Reporting format 'text/plain' 09:12:47.161743 Shared Clipboard: X11 reported available VBox formats: 0x5 09:12:47.161745 Shared Clipboard: Reporting formats 0x5 to guest 09:13:04.413114 Shared Clipboard: 14 formats were found 09:13:04.413138 Shared Clipboard: Found target 'TIMESTAMP' 09:13:04.413142 Shared Clipboard: Found target 'TARGETS' 09:13:04.413145 Shared Clipboard: Found target 'MULTIPLE' 09:13:04.413147 Shared Clipboard: Found target 'SAVE_TARGETS' 09:13:04.413149 Shared Clipboard: Found target 'text/html' 09:13:04.413151 Shared Clipboard: Found target 'text/_moz_htmlcontext' 09:13:04.413154 Shared Clipboard: Found target 'text/_moz_htmlinfo' 09:13:04.413156 Shared Clipboard: Found target 'UTF8_STRING' 09:13:04.413158 Shared Clipboard: Found target 'COMPOUND_TEXT' 09:13:04.413160 Shared Clipboard: Found target 'TEXT' 09:13:04.413162 Shared Clipboard: Found target 'STRING' 09:13:04.413164 Shared Clipboard: Found target 'text/plain;charset=utf-8' 09:13:04.413167 Shared Clipboard: Found target 'text/plain' 09:13:04.413169 Shared Clipboard: Found target 'text/x-moz-url-priv' 09:13:04.413176 Shared Clipboard: Reporting format 'text/html' 09:13:04.413180 Shared Clipboard: Reporting format 'UTF8_STRING' 09:13:04.413184 Shared Clipboard: Reporting format 'TEXT' 09:13:04.413186 Shared Clipboard: Reporting format 'STRING' 09:13:04.413189 Shared Clipboard: Reporting format 'text/plain;charset=utf-8' 09:13:04.413192 Shared Clipboard: Reporting format 'text/plain' 09:13:04.413195 Shared Clipboard: X11 reported available VBox formats: 0x5 09:13:04.413198 Shared Clipboard: Reporting formats 0x5 to guest 09:18:34.683023 Shared Clipboard: 10 formats were found 09:18:34.683049 Shared Clipboard: Found target 'TIMESTAMP' 09:18:34.683053 Shared Clipboard: Found target 'TARGETS' 09:18:34.683056 Shared Clipboard: Found target 'MULTIPLE' 09:18:34.683058 Shared Clipboard: Found target 'SAVE_TARGETS' 09:18:34.683060 Shared Clipboard: Found target 'UTF8_STRING' 09:18:34.683062 Shared Clipboard: Found target 'COMPOUND_TEXT' 09:18:34.683065 Shared Clipboard: Found target 'TEXT' 09:18:34.683067 Shared Clipboard: Found target 'STRING' 09:18:34.683070 Shared Clipboard: Found target 'text/plain;charset=utf-8' 09:18:34.683072 Shared Clipboard: Found target 'text/plain' 09:18:34.683078 Shared Clipboard: Reporting format 'UTF8_STRING' 09:18:34.683082 Shared Clipboard: Reporting format 'TEXT' 09:18:34.683085 Shared Clipboard: Reporting format 'STRING' 09:18:34.683087 Shared Clipboard: Reporting format 'text/plain;charset=utf-8' 09:18:34.683090 Shared Clipboard: Reporting format 'text/plain' 09:18:34.683092 Shared Clipboard: X11 reported available VBox formats: 0x1 09:18:34.683095 Shared Clipboard: Reporting formats 0x1 to guest 09:26:17.598283 Shared Clipboard: Guest wants to read 4096 bytes host clipboard data in format 1 09:26:17.598847 Shared Clipboard: Converting X11 format 'UTF8_STRING' to VBox format 0x1 09:26:17.598869 shClSvcClientReadData: Shared Clipboard: DATA/Host: cbData=4096->12 rc=VINF_SUCCESS 09:26:18.657968 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:26:48.660147 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3) failed, rc=VERR_TIMEOUT 09:26:48.661770 Shared Clipboard: Guest writes 84 bytes clipboard data in format 1 to host 09:26:48.662878 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:26:48.663166 Shared Clipboard: Guest writes 84 bytes clipboard data in format 1 to host 09:31:21.433643 Shared Clipboard: 10 formats were found 09:31:21.433668 Shared Clipboard: Found target 'TIMESTAMP' 09:31:21.433673 Shared Clipboard: Found target 'TARGETS' 09:31:21.433675 Shared Clipboard: Found target 'MULTIPLE' 09:31:21.433677 Shared Clipboard: Found target 'SAVE_TARGETS' 09:31:21.433679 Shared Clipboard: Found target 'UTF8_STRING' 09:31:21.433681 Shared Clipboard: Found target 'COMPOUND_TEXT' 09:31:21.433684 Shared Clipboard: Found target 'TEXT' 09:31:21.433686 Shared Clipboard: Found target 'STRING' 09:31:21.433688 Shared Clipboard: Found target 'text/plain;charset=utf-8' 09:31:21.433690 Shared Clipboard: Found target 'text/plain' 09:31:21.433697 Shared Clipboard: Reporting format 'UTF8_STRING' 09:31:21.433701 Shared Clipboard: Reporting format 'TEXT' 09:31:21.433704 Shared Clipboard: Reporting format 'STRING' 09:31:21.433707 Shared Clipboard: Reporting format 'text/plain;charset=utf-8' 09:31:21.433710 Shared Clipboard: Reporting format 'text/plain' 09:31:21.433713 Shared Clipboard: X11 reported available VBox formats: 0x1 09:31:21.433715 Shared Clipboard: Reporting formats 0x1 to guest 09:37:34.332089 PulseAudio: Retrieving server information ... 09:50:38.879646 PulseAudio: Retrieving server information ... 09:51:30.631386 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:51:30.648943 Shared Clipboard: Guest writes 766 bytes clipboard data in format 1 to host 09:54:14.328810 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 09:54:14.334860 Shared Clipboard: Guest writes 766 bytes clipboard data in format 1 to host 09:54:16.981661 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 09:54:16.981906 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 10:00:33.686972 PulseAudio: Retrieving server information ... 10:14:40.270272 Shared Clipboard: Converting VBox formats 0x1 to 'text/plain;charset=utf-8' for X11 12:14:27.293658 PulseAudio: Retrieving server information ... 12:14:27.299351 PulseAudio: Retrieving server information ... 12:15:56.355158 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago 12:15:56.537034 VMMDev: GuestHeartBeat: Guest is alive (gone 4 182 342 172 ns) 14:38:18.693509 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago 14:38:18.846145 VMMDev: GuestHeartBeat: Guest is alive (gone 4 152 676 794 ns) 14:39:50.504656 VMMDev: Guest Additions capability report: (0x4 -> 0x0) seamless: no, hostWindowMapping: no, graphics: no 14:39:50.510125 Shared Clipboard: Signalling the X11 event thread to stop 14:39:50.510156 Shared Clipboard: Waiting for X11 event thread to stop ... 14:39:50.529865 Shared Clipboard: X11 event thread stopped successfully 14:39:54.551350 VMMDev: Guest Log: VBOXNP: DLL loaded. 14:39:58.438126 VMMDev: Guest Log: 15:32:15.523502 control Guest control service stopped 14:39:58.552451 VMMDev: Guest Log: 15:32:15.617252 control Guest control worker returned with rc=VINF_TRY_AGAIN 14:39:58.552734 VMMDev: Guest Log: 15:32:15.617252 main Session 0 is about to close ... 14:39:58.553122 VMMDev: Guest Log: 15:32:15.617252 main Stopping all guest processes ... 14:39:58.553719 VMMDev: Guest Log: 15:32:15.617252 main Closing all guest files ... 14:39:58.586529 VMMDev: Guest Log: 15:32:15.648502 main Ended. 14:40:09.016177 VMMDev: Guest requests the VM to be turned off 14:40:09.016238 Changing the VM state from 'RUNNING' to 'POWERING_OFF'
I see there is a delay between "Shared Clipboard: Guest writes XXX bytes" and "Shared Clipboard: YYY formats were found" lines in the log. May be this is causing the delay and timeout?
comment:73 by , 4 years ago
When I copy some text by keyboard shortcut or by mouse click, the guest OS stop responding for some minutes now an then.
VirtualBox 6.1.16 r140961(Qt5.12.8)
HOST: Ubuntu 20.04LTS Desktop
GUEST: Win10 x64/Ubuntu 20.04LTS/Ubuntu16.04LTS
All these 3 GUEST OS can occurred.
follow-up: 75 comment:74 by , 3 years ago
kinlion, can you repeat your tests with Guest Additions from 6.1.30? We fixed quite a few additional bugs in the clipboard code since 6.1.16, and the symptom of at least one of them was clipboard hangs.
comment:75 by , 3 years ago
Replying to klaus
You didn't ask me, but I've checked the new 6.1.30 and can confirm that the temporal freezes (discussed here in comment 42 and 72) are occurring just like before. It seems that kinlion refer to them. I also made an easy way to reproduce them for myself using simple python program on WinXP guest and Ubuntu 20.04 host. This is the python program you may run on the guest:
from random import randrange
code = str(randrange(1000))
print(code)
try:
from Tkinter import Tk
except ImportError:
from tkinter import Tk
r = Tk()
r.withdraw()
r.clipboard_clear()
r.clipboard_append(code)
r.update() # now it stays on the clipboard after the window is closed
r.destroy()
then open firefox on the host and try to paste there, on my computer it almost always freezes for a few seconds on first try, may require some repeats.
But temporal freezes is the other issue from the segfaults and the current issue "VM segfaults on copy with shared clipboard" seems to be fixed a year ago. Temporal freezes never fixed.
comment:76 by , 3 years ago
Just to note the recent 6.1.32 release still suffer from the described freezes that can easily be reproduced using the python script I posted before. Not sure what "HTML content exchange" was fixed but it is not relevant. I just assumed for myself that the shared clipboard will never be fixed in VB on linux host. No hope.
comment:78 by , 3 years ago
After the start it prints this:
00:01:10.419249 Shared Clipboard: Starting X11 event thread ... 00:01:10.421562 Shared Clipboard: X11 event thread started 00:01:10.421576 Shared Clipboard: Reporting formats 0x0 to guest 00:01:10.421673 Shared Clipboard: 0 formats were found 00:01:10.421682 Shared Clipboard: X11 reported available VBox formats: 0x0
Then I made a few successful copy paste operation, run the python script multiple times in a row, then switched to the host and the last row in the log is what have caused freeze on the host:
00:01:26.989959 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 00:01:26.991500 Shared Clipboard: Guest writes 14 bytes clipboard data in format 1 to host 00:01:31.844640 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 00:01:31.846250 Shared Clipboard: Guest writes 14 bytes clipboard data in format 1 to host 00:01:31.846618 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 00:01:32.601025 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 00:01:32.602603 Shared Clipboard: Guest writes 14 bytes clipboard data in format 1 to host 00:01:32.602999 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 00:01:33.138939 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 00:01:33.248923 Shared Clipboard: Guest writes 0 bytes clipboard data in format 0 to host 00:02:03.139035 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3, atomTarget='UTF8_STRING') failed, rc=VERR_TIMEOUT
I've posted the log with similar error multiple times here. Please try to reproduce it yourself. Follow the simple steps I described in the comment 75. This algorithm works very consistent in reproducing the bug.
How this VERR_TIMEOUT and freeze even happened? Do you have a function on the host that sends requests to the client and freezing the host until it gets UTF8 string from the client? This is unacceptable. It is a security breach that allows a compromised guest to disrupt hosts activity. It should work asynchronously and return nothing if it has no data readily available. And requests shouldn't pile up on the client side too. Can you start a new thread on each such time consuming operation or what not? There should be a simple solution other than manual patching conversion operation among all possible format pairs.
follow-up: 80 comment:79 by , 3 years ago
Hi GnomeUser,
So far, the issue you are facing is not reproducible on my end (with and without a script from comment 75). It's been a while since last log was attached here and we have a number of changes in this area since then. Partial log snippets do not bring much more new information. Therefore, I would like to ask you to attach complete log file (as a file).
follow-ups: 82 83 comment:81 by , 3 years ago
Hi GnomeUser,
Thank you for the log. Can it be a case if guest is running an application which might hold system clipboard for a long time preventing other applications from accessing it?
comment:82 by , 3 years ago
It is a bug on the host. It is host that freeze. Host shall never freeze no matter what is running on a guest. You should consider guest compromised and vicious whenever you design an interface between host and guest. On the guest I just run this python script posted before. Such freezes occur with different guest OS, WinXP, Win10, which have a very different set of installed programs, also it is never a problem to copy&paste on the guest itself.
comment:83 by , 3 years ago
To reproduce this bug with Win10 guest I run that already posted python/Tk script ten times continuously using this windows shell command "FOR /L %i IN (1,1,10) DO python test.py" then try to paste into firefox address line on the host. It always reproduce the issue on Ubuntu 20.04 host for any windows guest basically.
comment:84 by , 3 years ago
Hi
I began to suffer from issue described by the GnomeUser after I updated host OS from Ubuntu 18.04 to Ubuntu 20.04.
The version of VirtualBox did not changed (6.1.32). And I use the same guest instance (guest OS Ubuntu 20.04).
Example from log:
04:04:08.775572 Shared Clipboard: Converting VBox formats 0x1 to 'UTF8_STRING' for X11 (idxFmtX11=1, fmtX11=3, atomTarget='UTF8_STRING') failed, rc=VERR_TIMEOUT
It's hard to say anything for sure. The clipboard work unstable. After the VERR_TIMEOUT issue, clipboard buffer on guest begins to independed from host.
Updated:
I looked around a bit more, and it looks like copying does happen. But a very long time passes from the moment of copying on the guest to the moment when the fragment can be pasted on the host. If I press Ctrl+V on the host continuously, after about 30 seconds, the fragment is pasted.
Updated:
The clipboard start behave unadequate when I use RDP client and copy text several time from guest RDP connection to host system and vise versa. I tried xfreerdp and remmina with same result.
comment:85 by , 17 months ago
No activity here for a while, but this just happened to me.
Host is Ubuntu 22.04, Guest is Ubuntu 20.04. Took a screenshot in the guest, clicked on "copy" and as soon as I did it crashed not only the guest but my host as well! Never seen that happen before, a VM crashing the host. Logged me out completely, had to log back in. Dmesg on the host had this in it:
[2625277.682158] VirtualBoxVM[889874]: segfault at 0 ip 00007ff0f4b18b08 sp 00007ffc95971cc8 error 4 in libQt5Gui.so.5.15.3[7ff0f4b0c000+4df000]
[2625277.682172] Code: 4d 00 48 89 44 24 18 31 c0 e8 f4 a8 ff ff 48 8b 44 24 28 64 48 2b 04 25 28 00 00 00 74 05 e8 ef 88 ff ff 31 c0 48 83 c4 38 c3 <48> 8b 04 25 00 00 00 00 0f 0b 48 8b 05 37 36 4d 00 66 0f ef c0 48
[2625277.774722] traps: SHCLX11[1108907] general protection fault ip:7fd431c373fc sp:7fd3bc1fc900 error:0 in libc.so.6[7fd431c1a000+68000]
Don't know if it is relevant, but the machine log contains a bunch of these lines:
441:14:18.382047 Shared Clipboard: Converting X11 format 'text/plain;charset=utf-8' (idxFmtX11=3) to VBox format 0x1 failed, rc=VERR_NO_DATA
441:14:18.382678 Shared Clipboard: Converting X11 format 'text/plain;charset=utf-8' (idxFmtX11=3) to VBox format 0x1 failed, rc=VERR_NO_DATA
Using VirtualBox v7.0.8 r156879 (Qt5.15.3), and guest additions are installed.
Tried to repro, but did not see the problem happen again.
Sorry, version is 6.1.2, not 6.0.12. I don't think I can edit the selected version, unfortunately.