Opened 9 years ago
Closed 7 years ago
#14585 closed defect (fixed)
When VM locks up, GUI is unresponsive.
Reported by: | arleslie | Owned by: | |
---|---|---|---|
Component: | GUI | Version: | VirtualBox 5.0.4 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Linux |
Description
When a VM locks up (due to high resource usage/large data transfers to USB) if you go to reset/restart the VM normally the Not Responding will display. If you close this the "Close Virtual Machine" window will open but will not respond, this will also lock up the VirtualBox Manager screen.
When issuing "vboxmanage controlvm <vmname> reset" it returns:
VBoxManage: error: Invalid machine state: Paused VBoxManage: error: Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component ConsoleWrap, interface IConsole, callee nsISupports VBoxManage: error: Context: "Reset()" at line 127 of file VBoxManageControlVM.cpp
Host OS: Fedora 22 Guest OS: Fedora 20
Change History (3)
comment:2 by , 9 years ago
Not really sure if I should make a bug report for it locking up but here's what an strace spits out when it locks up
futex(0x7fd50919b444, FUTEX_WAIT_BITSET_PRIVATE, 38010, {314194, 150025033}, ffffffff) = -1 ETIMEDOUT (Connection timed out) futex(0x7fd50919b470, FUTEX_WAKE_PRIVATE, 1) = 0 sched_yeild() = 0 futex(0x7fd50919b444, FUTEX_WAIT_BITSET_PRIVATE, 38014, {314194, 650355122}, ffffffff) = -1 ETIMEDOUT (Connection timed out) futex(0x7fd50919b470, FUTEX_WAKE_PRIVATE, 1) = 0 sched_yeild() = 0 futex(0x7fd50919b444, FUTEX_WAIT_BITSET_PRIVATE, 38018, {314194, 150621370}, ffffffff) = -1 ETIMEDOUT (Connection timed out) futex(0x7fd50919b470, FUTEX_WAKE_PRIVATE, 1) = 0 sched_yeild() = 0 futex(0x7fd50919b444, FUTEX_WAIT_BITSET_PRIVATE, 38022, {314194, 650920677}, ffffffff) = -1 ETIMEDOUT (Connection timed out) futex(0x7fd50919b470, FUTEX_WAKE_PRIVATE, 1) = 0 sched_yeild() = 0
comment:3 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Please reopen if still relevant with VBox 5.1.22.
When using kill -9 on the VM process, it also kills the VirtualBox Manager Screen.
--Edit-- I noticed this isn't always the case. If the VM and the Manager GUI's both lock up then it will terminate both. If only the VM GUI get's locked up then it will only terminate that one.