Opened 16 years ago
Closed 11 years ago
#3207 closed defect (fixed)
Saving execution state hangs at 97% -> retry with 2.1.4
Reported by: | karl | Owned by: | |
---|---|---|---|
Component: | guest additions | Version: | VirtualBox 2.1.2 |
Keywords: | execution state clipboard | Cc: | |
Guest type: | Linux | Host type: | Windows |
Description (last modified by )
Hi, Saving the execution state on XP host with ubuntu 8.04 guest often hangs at 97%, where it stays forever. It may be linked to another bug I'm experiencing with virtuabox locking the windows clipboard, thus preventing other windows software to use it
Attachments (4)
Change History (19)
by , 16 years ago
comment:3 by , 16 years ago
I got the exact same problem, but with Ubuntu 8.10 64 bit as host and Windows XP as guest
comment:4 by , 16 years ago
Summary: | Saving execution state hangs at 97% → Saving execution state hangs at 97% -> retry with 2.1.4 |
---|
by , 16 years ago
Attachment: | VBox.2.log added |
---|
comment:6 by , 15 years ago
dgrant, any chance to reproduce this problem with 2.2.4? If so, could you generate a core dump and send it to me at frank _dot_ mehnert _at_ sun _dot_ com? This sounds like a deadlock and a core dump from a Linux box would help us debug the problem.
comment:7 by , 15 years ago
Ok, I've started VirtualBox with the appropriate settings and as soon as I can reproduce the hang, I'll get the core dump.
comment:8 by , 15 years ago
I have same problem most times I try to suspend the machine: Saving execution state hangs with no CPU usage for virtualbox. So no loop. Looks like this maybe linked to the shared Clipboard issue. After some time the cut&pate does not work anymore on the HOST system. I can only resolve this by reboot of the host system. And it looks like if this occurs I also do have the hang at 97% in SAVING THE EXECUTION STATE.
HOST: WinXP Prof, SP3 Guest: SUSE Linux 10.2 VirtualBox: 2.2.4 r47978
comment:9 by , 15 years ago
By the way: after I kill the virtual guest system on my host the cut&paste works fine again on the host system
comment:10 by , 15 years ago
I still haven't been able to reproduce the problem, but as soon as it does happen, I hope to have a core dump.
comment:11 by , 14 years ago
Please test with 3.2.0, and tell us if the problem still exists
-Technologov
comment:12 by , 14 years ago
Hi, I had the issue in the past, but never noticed it was (or not) at 97% However, today, I had the issue and wanted to know more about it. That's how I found this bug report. I have a Windows XP host running VirtualBox 3.2.10 and Ubuntu 10.10 64bits client. The issue today, is reversed: I had the clipboard failing on Windows and after unsuccessful retries to fix it, I decided to reboot Windows. So, I saved Virtual Box state and it stopped at 97% !! I rebooted anyway and got a Windows error message saying that "VBoxSharedClipboardClass" was not responding.
The Windows XP clipoard hangs frequently, and it looks like VirtualBox hangs too at saving the execution state at 97% if windows clipboard is in an invalid state. I don't know if cliboard content is saved at this moment, but the solution would be either not to store the clipboard content in the machine state (as not very useful - clipboard is only temporary data) or find a way to test the clipboard behavior and save the content according to its state (running or hanged).
Hope this will help solving this issue.
by , 14 years ago
Attachment: | Ubuntu-64-2-2010-11-16-11-17-29.log added |
---|
related to my first post on this topic
comment:13 by , 13 years ago
I'm facing exactly the same issue on 4.0.10. It only happens with my CentOS client. As the host system I have XP. And yes, every time the saving hangs, I can't use copy-past even on the host system and once I have killed the hanged savin process the copy-paste starts to work again.
by , 13 years ago
Attachment: | Save failing.log added |
---|
comment:15 by , 11 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Good question. I assume that we would have seen reports if this would be the case. I will close this ticket, please reopen if this still happens with VBox 4.3.2. In that case, please attach a VBox.log file of such a VM session.
log