Copy+Paste in GUI dialog boxes freezes GUI (Windows hosts)

[Wouter Kariboe]

VirtualBox.exe very frequently freezes upon Copy+Paste within the "Details of ..." dialog box and in the Settings dialog box (e.g. Details => General => Description). In the latter case I end up with an "Aborted" VM - even though I haven't run it!

I'm not sure if I should have reopened the closed/fixed ticket #2065 for this, but that didn't mention the freeze I'm experiencing.

This problem seems unrelated to the familiar copy/paste problems between host and guest (e.g. tickets #3303, #3211, #2563 etc.). In any case no running guests are involved here: just VirtualBox.exe.

Steps:

1. Under Windows XP Professional (+SP3), start VirtualBox.exe (vs. 3.0.2).

2. Enter an existing VM snapshot's "Details of ..." dialog box (via the "Show Details" button or Ctrl+Space). (I don't recommend using Details => General => Description to test this, since it may lead to an "Aborted" VM!)

3. Select some of the existing text in the Name editbox, then press Ctrl+Insert or Ctrl+C.

4. Optional: enter the Description editbox.

5. Press Shift+Insert or Ctrl+V: very often VirtualBox.exe freezes and the cursor turns into an hourglass - I then have to kill VirtualBox.exe.

The problem seems to be with the copying rather than the pasting: when I copy something to the Windows clipboard from a different application (e.g. Notepad), the Details dialog box always pastes that text correctly.

Accordingly, text copied from the Details dialog box (step 3 above) can sometimes be pasted into other applications, sometimes not (although the receiving applications never freeze).

N.B. I've encountered this problem in versions before 3.0.2 as well, at least going back to 2.2.0, probably earlier.

[Technologov]

I also experience such issues.

I have found a way to reproduce this on Windows 7/x64 host with VBox 3.1.0. This ugly bug (Qt?) results in crash of VBox GUI and corrupts clipboard in Windows host.

Steps to reproduce: (sometimes reproducible)

1. Create a new VM named "Fedora07 32-bit SMP" (type from keyboard; something long with spaces)

2. Copy it (VM settings->General->Name field->select->ctrl+C)

3. Create a new VM named "Fedora07 32-bit SMP" (paste it, Ctrl+V)

VBox GUI will freeze, when trying to press "X", it will Crash.

NOTE: The problem begins with Copy --- if you paste it to Windows Notepad (after step 2), nothing will be pasted. Basically it zeroes Windows Host Clipboard.

But if the source is text copied from Windows Notepad, then step 3 will succeed. It seems that Qt crashes when zero-size clipboard string is pasted into it.

This looks like there are basically 2 bugs:

1. Copy results in zero-size clipboard string

2. Paste of zero-size clipboard string results in VBox GUI crash.

Bug #1 was not reproducible on RHEL 5/x64 host. So I can't test Bug #2.

Is there a way to artificially create zero-size clipboard strings on other host platforms?

-Technologov

[demonGeek]

I am also experiencing this problem.

VBox v3.1.4r57640 running on Win7 x64 host.

Only occurs in the VBox management console and is not related to whether any VM's are running although when it occurs it may also kill any VM's that happen to be running which is really bad.

The copy must first be initiated on a field in the management console and the hang happens when the paste operation is triggered. It does not matter whether the paste operation is in the management console or an external application.

Although not 100% persistent, the problem does occur frequently and is always fatal. It has been responsible for damaging the virtual disk on one of my VM's that happened to be running at the time the problem occurred.

From reading the original bug report, it seems this has been around a while - I'm a new VBox user so I can't confirm that but it does seem strange that more effort is not being made to fix something that is capable of rendering a VM useless. At the very least disable the copy/paste functionality as a short-term fix.

[Technologov]

Is there a way to artificially create such empty or null strings?

This crashes GUI, so I recommend upping the priority to critical.

-Technologov

[Wouter Kariboe]

Several issues:

1. SEVERITY LEVEL:

When I created this bug ticket (my first!), I didn't want to shout overly loud, but I regret now that I didn't give it a higher priority. "Critical" would be fine with me!

2. REPRODUCTION VIA CLIPBOOK VIEWER:

I can now reproduce this bug by just copying data from the VirtualBox.exe to the Windows (XP Professional + SP3) clipboard. (I.e. without pasting back to the VirtualBox.exe.)

Steps:

Start C:\WINDOWS\system32\clipbrd.exe ("ClipBook Viewer").

Start VirtualBox.exe (vs. 3.1.6) and open a VM's dialog box (as described in my original report).

Copy some text from VirtualBox to the clipboard and watch the clipboard window within ClipBook Viewer:

In many cases both VirtualBox and ClipBook Viewer freeze (hourglass showing, etc.).

Then when I kill VirtualBox, ClipBook Viewer unfreezes and displays the message "The information is in a binary format. ClipBook Viewer cannot display this format. To view the information, try pasting it into a document."

I’ve also seen "ClipBook Viewer cannot display the information in its current format or there is not enough memory to display it. Quit one or more applications to increase the available memory, and then try again."

And when I've managed to save some invalid clipboard data to file via ClipBook Viewer's File -> "Save As" operation, that file indeed contains garbage. (However, I'm not sure how "interesting" this file data is, i.e. to what degree the saved format mirrors the actual clipboard content.)

In any case, it seems that VirtualBox often puts invalid data on the Windows clipboard, perhaps even causing the Windows clipboard server to go haywire.

I can't say what is exactly going wrong here:

Maybe the TYPE indicator of the data being put on the clipboard doesn't get initialized (remember that you can put many different types of data on the Windows clipboard).

Alternatively there might be some problem concerning the appropriation ("hooking"?) of the clipboard by VirtualBox.exe: that would explain why ClipBook Viewer unfreezes when I kill VirtualBox.exe.

3. RELATED BUG TICKET?

I've begun to suspect that this GUI problem is actually caused by the same bug as the problem reported concerning host-guest copying/pasting, ticket #3303. That one also mainly seems to concern Windows hosts.

So my guess is that the bug is in the VirtualBox interface to the Windows clipboard (VBoxClipboard.cpp?).

I'm not sure what this would mean for the status of these bug tickets ("resolved as duplicate" etc.). Strictly speaking we might have to create a new ticket for the "general" bug, but that seems a bit pointless. In any case it will probably be easier to tackle this bug concerning only the GUI, rather than in the more complex situation when a running guest is involved.

[Technologov]

Still crashes with 3.2.0

-Technologov

[Technologov]

Please up priority to critical.

[Technologov]

Found Duplicates of this bug: #5730 and #4967

-Technologov

[Guido Kroon]

This annoying problem still occurs in v3.2.8. This happens only on Windows hosts to me (XP as well as Vista and 7). I'm not experiencing the same issue on my Ubuntu and Linux Mint hosts though.

[Frank Mehnert]

To clarify: This problem is known but there is currently no known solution. The bug is deep inside the Qt library and the way we have to use it together with the Windows COM initialization.

[Technologov]

Since you're a paying customer of Nokia's Qt, you can try to ask them.

-Technologov

[Technologov]

Oracle: Can you please take another look at it ?

This really plagues user experience, and I hope to see this fixed for v4.0.

-Technologov

[naksu]

This bug is still present in version 4.0.6. It also doesn't seem to always require a copy+paste - I've had the GUI freeze when starting to type in a name for the snapshot.

[Frank Mehnert]

Yes, the bug will be fixed in the next major release as the fix is quite invasive.

[Frank Mehnert]

Finally fixed in 4.1.0.