VirtualBox

Ticket #19226 (accepted defect)

Opened 11 months ago

Last modified 3 days ago

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:

  1. Start VM and login
  2. Open libreoffice calc on host
  3. 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

VBox.log Download (87.9 KB) - added by hotjava1231 9 months ago.
coredumpctl_info.txt Download (6.1 KB) - added by hotjava1231 3 months ago.
output of coredump tool on crashed VirtualBox process

Change History

comment:1 Changed 11 months ago by udine

Sorry, version is 6.1.2, not 6.0.12. I don't think I can edit the selected version, unfortunately.

comment:2 Changed 11 months ago by fbatschu

  • Version changed from VirtualBox 6.0.12 to VirtualBox 6.1.2

comment:3 Changed 11 months ago by SBach

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 Changed 10 months ago by tageloehner

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

Last edited 10 months ago by tageloehner (previous) (diff)

comment:5 Changed 10 months ago by EdRoxter

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.

Last edited 10 months ago by EdRoxter (previous) (diff)

comment:6 Changed 10 months ago by skorupa

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 Changed 10 months ago by nubaltec

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.

Last edited 10 months ago by nubaltec (previous) (diff)

comment:8 Changed 10 months ago by Taz31

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 Changed 10 months ago by Wick

Same here.

DMESG: ShClipboard[32685]: segfault at 4 ip 00007f6bc410037b sp 00007f6bc4186d00 error 4 in VBoxSharedClipboard.so[7f6bc40f9000+8000]

Host: fedora 31 ( 5.4.17-200.fc31.x86_64 ) with Gnome / Wayland
Guest: Windows 10 ( 1809 Build: 17763.973 )
Virtualbox: 6.1.2 r135662

Last edited 10 months ago by Wick (previous) (diff)

comment:10 Changed 10 months ago by wazzup105

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

Changed 9 months ago by hotjava1231

comment:11 Changed 9 months ago by hotjava1231

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 Changed 9 months ago by fbatschu

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

Last edited 8 months ago by fbatschu (previous) (diff)

comment:13 Changed 9 months ago by David29

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.

Last edited 9 months ago by David29 (previous) (diff)

comment:14 Changed 9 months ago by EdRoxter

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...

Last edited 9 months ago by EdRoxter (previous) (diff)

comment:15 Changed 9 months ago by fbatschu

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 Changed 9 months ago by fbatschu

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));                  
Last edited 9 months ago by fbatschu (previous) (diff)

comment:17 follow-up: ↓ 21 Changed 9 months ago by 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.

Last edited 9 months ago by Jan Kalina (previous) (diff)

comment:18 Changed 8 months ago by GnomeUser

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?

comment:19 follow-up: ↓ 20 Changed 7 months ago by Kévin Leroy

  • Status changed from new to 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 in reply to: ↑ 19 Changed 7 months ago by fbatschu

  • Status changed from awaitsfeedback to 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]


https://www.virtualbox.org/ticket/19226#comment:15

comment:21 in reply to: ↑ 17 ; follow-up: ↓ 22 Changed 7 months ago by EdRoxter

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 in reply to: ↑ 21 Changed 6 months ago by Solerman

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 Changed 6 months ago by simonc

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 Changed 6 months ago by simonc

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

Last edited 6 months ago by simonc (previous) (diff)

comment:25 Changed 6 months ago by chaker

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.

Last edited 6 months ago by chaker (previous) (diff)

comment:26 Changed 5 months ago by wjprakash

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.

Last edited 5 months ago by wjprakash (previous) (diff)

comment:27 Changed 5 months ago by ttosttos

Last edited 5 months ago by ttosttos (previous) (diff)

comment:28 Changed 4 months ago by linus100

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 Changed 4 months ago by Goodwin

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:30 Changed 3 months ago by pentagonik

I'll have a look at this, thanks for the additional information.

comment:31 Changed 3 months ago by pentagonik

  • Owner set to pentagonik
  • Status changed from new to accepted

comment:32 Changed 3 months ago by pentagonik

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 Changed 3 months ago by linuxbastler

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:34 Changed 3 months ago by pentagonik

Cheers, thanks for verifying!

comment:35 Changed 3 months ago by simonc

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

Changed 3 months ago by hotjava1231

output of coredump tool on crashed VirtualBox process

comment:36 Changed 3 months ago by hotjava1231

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 Changed 3 months ago by 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.

comment:38 follow-up: ↓ 41 Changed 3 months ago by pentagonik

@hotjava1231 Also, can you tell if this is reproducible for you, and if so, how to exactly reproduce the issue?

comment:39 Changed 3 months ago by shellster

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 Changed 3 months ago by simonc

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 in reply to: ↑ 38 Changed 3 months ago by hotjava1231

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 Changed 3 months ago by GnomeUser

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 Changed 2 months ago by GnomeUser

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 Changed 2 months ago by GnomeUser

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 Changed 2 months ago by ----------

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]
Last edited 7 weeks ago by ---------- (previous) (diff)

comment:46 Changed 6 weeks ago by pentagonik

Thanks for the additional information -- I'll have another peek at this in a short while.

comment:47 follow-up: ↓ 48 Changed 6 weeks ago by pentagonik

@----------: 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 in reply to: ↑ 47 Changed 6 weeks ago by GnomeUser

@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 Changed 5 weeks ago by Borrelworst

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

Last edited 5 weeks ago by Borrelworst (previous) (diff)

comment:50 Changed 5 weeks ago by pentagonik

@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:51 Changed 5 weeks ago by pentagonik

See here about how to provide a core dump to us.

comment:52 Changed 5 weeks ago by GnomeUser

@pentagonik have you tried to restart the guest addition VBoxTray.exe and copy paste multiple times as I describe in comment #44?

comment:53 Changed 5 weeks ago by pentagonik

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 Changed 5 weeks ago by pentagonik

@GnomeUser Do see something like "Shared Clipboard: Stopping X11 event thread failed [...]" in your log before it crashes?

comment:55 Changed 5 weeks ago by GnomeUser

@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

Last edited 5 weeks ago by GnomeUser (previous) (diff)

comment:56 Changed 5 weeks ago by pentagonik

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 Changed 5 weeks ago by pentagonik

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 Changed 5 weeks ago by GnomeUser

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 Changed 4 weeks ago by pentagonik

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 Changed 4 weeks ago by GnomeUser

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 Changed 4 weeks ago by GnomeUser

@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 Changed 3 weeks ago by Borrelworst

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.

comment:63 follow-up: ↓ 66 Changed 3 weeks ago by 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!

comment:64 Changed 3 weeks ago by simonc

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 Changed 2 weeks ago by GnomeUser

@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 in reply to: ↑ 63 Changed 2 weeks ago by Borrelworst

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?

Last edited 2 weeks ago by Borrelworst (previous) (diff)

comment:67 follow-up: ↓ 71 Changed 2 weeks ago by 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.

comment:68 Changed 12 days ago by pentagonik

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 Changed 12 days ago by GnomeUser

@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.

Last edited 12 days ago by GnomeUser (previous) (diff)

comment:70 Changed 8 days ago by pentagonik

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.
Last edited 8 days ago by pentagonik (previous) (diff)

comment:71 in reply to: ↑ 67 Changed 7 days ago by eacb

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 Changed 3 days ago by GnomeUser

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?

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use