VirtualBox

Opened 7 years ago

Last modified 5 years ago

#16075 new defect

VBox "draganddrop" CPU Spike on Ubuntu Guest

Reported by: craymichael Owned by:
Component: drag and drop Version: VirtualBox 5.0.18
Keywords: draganddrop drag and drop cpu spike Cc: nopaste
Guest type: Linux Host type: Windows

Description

Version: 5.0.18_Ubuntur106667 Host: Windows 7 Professional Service Pack 1 64-Bit Guest: Ubuntu 16.04 LTS 64-Bit

I have a very peculiar issue with VirtualBox. To replicate on my machine: 1) Open Guest to desktop and leave open in one window 2) Open windows explorer and place on top of Guest 3) Drag arbitrary file from window on top of Guest to anywhere outside Guest, ensuring cursor with file moves over any section of Guest. 4) CPU immediately spikes to 100% with the two processes of the name "/usr/bin/VBoxClient --draganddrop" using the highest percentages

I've attached my logs to this ticket.

Attachments (5)

VBox.log (108.6 KB ) - added by craymichael 7 years ago.
VBox.log.1 (112.4 KB ) - added by craymichael 7 years ago.
VBox.log.2 (118.0 KB ) - added by craymichael 7 years ago.
VBox.log.3 (111.8 KB ) - added by craymichael 7 years ago.
VBoxHardening.log (350.3 KB ) - added by craymichael 7 years ago.

Download all attachments as: .zip

Change History (17)

by craymichael, 7 years ago

Attachment: VBox.log added

by craymichael, 7 years ago

Attachment: VBox.log.1 added

by craymichael, 7 years ago

Attachment: VBox.log.2 added

by craymichael, 7 years ago

Attachment: VBox.log.3 added

by craymichael, 7 years ago

Attachment: VBoxHardening.log added

comment:1 by Michael Thayer, 7 years ago

Cc: nopaste added

Added nopaste to CC.

comment:2 by Michael Thayer, 7 years ago

Component: clipboarddrag and drop

More or less quoting from ticket #14743: I am afraid that due to lack of resources we are not likely to be able to look at this in the foreseeable future. Since this is something that should be debuggable and hopefully fixable by someone with reasonable X11 programming experience I would suggest that someone affected take a look at the problem. I do not know this particular area of our code, but I am generally familiar with how our X11 and Linux Additions work, so I would be able to provide any necessary background knowledge as long as I do not have to invest too much time. Sorry about that, but let's make this an opportunity to get more people involved in VirtualBox development.

comment:3 by Sam Morris, 7 years ago

I've seen this over many versions, using Windows as a host and Linux as a guest. Dragging a file from Explorer over the guest window immediately causes VBoxClient --draganddrop to peg the CPU.

On a virtual machine using two cores, in htop I observe thread 1 using 120% of the CPU, and thread 3 using 60%. Presumably as a result of the client's requests to the X server, I also observe Xorg using 20% of the CPU.

Thread 4 (Thread 0x7ffff5149700 (LWP 7669)):
#0  0x00007ffff6de881d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1  0x00005555555c75e9 in RTThreadSleepNoLog (cMillies=<optimized out>)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/r3/posix/thread2-posix.cpp:114
#2  0x000055555558f08b in DragAndDropService::x11EventThread (
    hThread=<optimized out>, pvUser=0x55555586f9e0)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/x11/VBoxClient/draganddrop.cpp:3418
#3  0x00005555555adc1c in rtThreadMain (pThread=pThread@entry=0x55555588e1b0, 
    NativeThread=NativeThread@entry=140737305155328, 
    pszThreadName=pszThreadName@entry=0x55555588ea90 "dndX11")
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/common/misc/thread.cpp:717
#4  0x00005555555c72c0 in rtThreadNativeMain (pvArgs=0x55555588e1b0)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/r3/posix/thread-posix.cpp:327
#5  0x00007ffff6ddf464 in start_thread (arg=0x7ffff5149700)
    at pthread_create.c:333
#6  0x00007ffff691a9df in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 3 (Thread 0x7ffff51ca700 (LWP 7668)):
#0  0x00007ffff6912cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x00005555555d0b1c in vbglR3DoIOCtl (iFunction=iFunction@entry=3225441938, 
    pvData=pvData@entry=0x7ffff51c9bf0, cbData=cbData@entry=64)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/common/VBoxGuestLib/VBoxGuestR3Lib.cpp:424
#2  0x00005555555d2f5c in vbglR3DnDGetNextMsgType (
    pCtx=pCtx@entry=0x7ffff51c9d40, puMsg=puMsg@entry=0x7ffff51c9c58, 
    pcParms=pcParms@entry=0x7ffff51c9c5c, fWait=fWait@entry=true)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/common/VBoxGuestLib/VBoxGuestR3LibDragAndDrop.cpp:83
#3  0x00005555555d6368 in vbglR3DnDGetNextMsgType (fWait=true, 
    pcParms=0x7ffff51c9c5c, puMsg=0x7ffff51c9c58, pCtx=0x7ffff51c9d40)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/common/VBoxGuestLib/VBoxGuestR3LibDragAndDrop.cpp:70
#4  VbglR3DnDRecvNextMsg (pCtx=pCtx@entry=0x7ffff51c9d40, 
    pEvent=pEvent@entry=0x7ffff51c9d68)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/common/VBoxGuestLib/VBoxGuestR3LibDragAndDrop.cpp:1484
#5  0x000055555558aa56 in DragAndDropService::hgcmEventThread (
    hThread=<optimized out>, pvUser=0x55555586f9e0)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/x11/VBoxClient/draganddrop.cpp:3312
#6  0x00005555555adc1c in rtThreadMain (pThread=pThread@entry=0x55555588d8b0, 
    NativeThread=NativeThread@entry=140737305683712, 
    pszThreadName=pszThreadName@entry=0x55555588e190 "dndHGCM")
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/common/misc/thread.cpp:717
#7  0x00005555555c72c0 in rtThreadNativeMain (pvArgs=0x55555588d8b0)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/r3/posix/thread-posix.cpp:327
#8  0x00007ffff6ddf464 in start_thread (arg=0x7ffff51ca700)
    at pthread_create.c:333
#9  0x00007ffff691a9df in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7ffff7fc7780 (LWP 7663)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00005555555c8440 in rtSemEventWait (fAutoResume=true, 
    cMillies=cMillies@entry=4294967295, hEventSem=0x55555587ed60)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/r3/linux/../posix/semevent-posix.cpp:369
#2  RTSemEventWait (hEventSem=0x55555587ed60, 
    cMillies=cMillies@entry=4294967295)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Runtime/r3/linux/../posix/semevent-posix.cpp:482
#3  0x000055555558fbc0 in DragAndDropService::run (this=0x55555586f9e0, 
    fDaemonised=<optimized out>)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/x11/VBoxClient/draganddrop.cpp:3082
#4  0x0000555555582f42 in main (argc=<optimized out>, argv=<optimized out>)
    at /build/virtualbox-hJYAQp/virtualbox-5.1.12-dfsg/src/VBox/Additions/x11/VBoxClient/main.cpp:332

Killing the process causes everything to return to normal.

comment:4 by Qtax, 7 years ago

Same issue with version 5.1.18. Host: Windows 10 Pro (version 1703), Guest: Ubuntu 16.04 (Xubuntu)

I've seen this issue with "/usr/bin/VBoxClient --draganddrop" eating up a full core of CPU many times, and in older versions of VirtualBox. CPU usage doesn't seem to stop until the process is killed.

Colleagues who get this issue and are not paying attention to the CPU usage experience performance drop of other activities without understanding what's going on. As this process never stops the performance issue may last for a long time (as we usually don't reboot the guests often) leading to a bad user experience (especially if the guest doesn't have many cores assigned). Maybe such use cases could motivate a bit higher priority for the issue?

comment:5 by Olof, 6 years ago

Same problem on VirtualBox 5.2.4 (Windows 7 host if that matters). It happens several times a day and I have to kill the "/usr/bin/VBoxClient --draganddrop" process manually every time. I think this issue should have higher priority.

in reply to:  5 comment:6 by Socratis, 6 years ago

Replying to Olof:

I think this issue should have higher priority.

It really depends on who sets the priorities, no? And with which criteria. Just look at the open tickets that wait in queue to be fixed/addressed. And since there are known workarounds (networking, shared folders), and frankly since DnD is a luxury add-on, not available to all guests, I'm thinking that the priority may not be that high. But that's just me... ;)

comment:7 by Daniel, 6 years ago

I can confirm this still exists with VBox 5.2.18. I am on 64 bit Win10 host with multiple VM's which are 64bit Win 7 guest and a 64bit Debian Linux guest.

Both the Win 7 guest and Debian guest are impacted.

I have seen the problem occur more frequently when using copy-paste with Excel on the host (where I also have had Excel begin complaining that it can't access the clipboard when copying).

in reply to:  7 comment:8 by Daniel, 6 years ago

I have seen the problem occur more frequently when using copy-paste with Excel on the host (where I also have had Excel begin complaining that it can't access the clipboard when copying).

Based on what little bit I just learned - this sounds like a separate issue. In the interim, I am going to begin testing with DnD disabled.

in reply to:  7 comment:9 by Socratis, 6 years ago

Replying to dstrev:

I have seen the problem occur more frequently when using copy-paste with Excel on the host (where I also have had Excel begin complaining that it can't access the clipboard when copying).

That would be ticket #16192.

comment:10 by chriswyattuk, 5 years ago

I just had a similar issue, but with Lubuntu 18.10 as my host, and Lubuntu 18.04 as my guest. VBoxClient was using an entire core, suggesting it was maybe stuck in a continuous loop somewhere.

I managed to fix it by disabling the shared clipboard and drag and drop (both were set to bidirectional). When setting them both back to bidirectional again, the issue did not return.

It's frustrating I didn't try them one-by-one, as I'm not sure what triggered the issue.

Without knowing a thing about the code, I do wonder if it's something to do with bidirectional-ness, and/or some sort of race condition involving events.

Version 2, edited 5 years ago by chriswyattuk (previous) (next) (diff)

comment:11 by chriswyattuk, 5 years ago

It would not surprise me if this was some deeper issue in Linux (or perhaps the window manager), because I am constantly having mouse issues in Linux, and with each release the problem never goes away. Granted, I haven't filed any issues about it, so I haven't really helped the situation much.

There's one really annoying issue with my VM, where I'll be clicking around, and then the clicks will no longer be picked up. If I switch between virtual terminals with Ctrl-Alt-F[1-9], I can usually get the mouse to respond again. I feel like the mouse events get lost somewhere; if I've clicked somewhere, the click will eventually register when I do the terminal switching thing.

Sometimes it's just part of the screen that stops responding to clicks, sometimes the mouse cursor will completely disappear, and sometimes it can't be solved by switching terminals and I have to logout and then log back in again, either in the VM or host (as the issue can happen in both).

I also have an issue with file-roller and dragging/dropping, where it will start dragging, and never drop, and I have to kill file-roller. This could just be specific to file-roller, or may be part of a bigger issue.

I realise this is probably not related to this issue, but I thought I should mention it, on the off-chance it had any relevance. I mainly mentioned this to support my theory that mouse events in the window manager are a mess! It makes me wonder if there's a button down event, and applications are waiting for a button up event that never happens.

Last edited 5 years ago by chriswyattuk (previous) (diff)

comment:12 by bitbull, 5 years ago

I ghave the same issue with Windows 7 as host and Ubuntu 16.04 as guest. VBoxClent --draganddrop is eating 500+ MB and 50+ CPU. VBox version 5.2.18

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use