Opened 12 years ago
Closed 11 years ago
#11289 closed defect (fixed)
Closing window (and saving state) via keyboard causes abort on resume => Fixed in SVN
Reported by: | CaptainDave | Owned by: | |
---|---|---|---|
Component: | guest control | Version: | VirtualBox 4.2.4 |
Keywords: | Cc: | ||
Guest type: | all | Host type: | Linux |
Description
If you press the host window manager's close window key, e.g. Alt+F4 in Fluxbox or Windows+x in spectrwm/scrotwm, you are presented with the save state/shutdown/power off dialog as expected. However, if you choose to save the guest state, on restarting the VM, the progress bar goes to the end and then the VM aborts with a failed assertion regarding !VMCPU_FF_ISSET(pVCpu, VMCPU_FF_INTERRUPT_PIC).
Stopping and saving the state of the guest by closing the window with the mouse, with the host key+q combination, or via "vboxmanage controlvm <VM> savestate" from a terminal all resume properly.
If I had to wager a guess as to what's wrong, it's that the guest expects the modifier key in the close combination, e.g. the Alt in Alt+F4, to be depressed when it resumes, as it certainly was when its state was saved, and it can't handle the unexpected condition.
Please note that bug number 8660 is largely repetitive of this, but the original reporter of that one didn't figure out the (or at least "this") cause of the problem. Plus, it's an old report of an old version.
Change History (9)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I have the same problem on 4.2.6. Pressing Alt+Shift+C on dwm to close the window and saving the VM state leads to fail on resume. But closing the VM using hostkey+q resumes properly. Is that possible VB doesn't handle X11-close-event and Qt-close-button(or shortcut) the same way ?
comment:3 by , 11 years ago
I can confirm the same issue on OSX 10.8.3 using Virtual Box 4.2.0 -> 4.2.10 with both Linux and WinXP guests. I'm just glad I now know what causes the issue, so I can avoid it.
In my case I've moved the host key to the right Command button. I observe the following:
- Closing by closing the window WORKS
- Closing using the X on the VirtualBox overlay menu (in full screen mode) WORKS
- Closing using the hostkey+q WORKS
- Closing using the left Command button + q DOESN'T WORK
comment:4 by , 11 years ago
FWIW - I appear to encounter this issue with OSX 10.6.8 and Virtual Box 4.2.0 --> 4.2.16 while only using my mouse to close VB. The only twist on the above, aside from versioning/OS/config differences is the following multiple screen pattern:
- start & save VM state with only one monitor, then restart with two --> Abort
- start & save VM state with two monitor, then restart with one --> Abort
- otherwise --> OK
The issue appears to be associated with this assertion error:
00:00:10.736320 !!Assertion Failed!! 00:00:10.736321 Expression: !VMCPU_FF_ISSET(pVCpu, VMCPU_FF_INTERRUPT_PIC) 00:00:10.736321 Location : /Users/vbox/tinderbox/4.2-mac-rel/src/VBox/VMM/VMMR3/PDM.cpp(902) int pdmR3LoadExec(VM*, SSMHANDLE*, uint32_t, uint32_t)
comment:5 by , 11 years ago
Same here. Any held-down keys that end in a savestate cause a crash when restoring. Steps for Win7 Pro host, guest irrelevant (take out any attached hard drives, this can be reproduced without loading into OS). Hold any key within the guest, e.g. Left Shift, then click "X" to close the VirtualBox window. At this point, the key is still registered as "down" or "pressed" within the guest, and you're facing the "Paused" VirtualBox window. If you Save State, the Guest won't resume.
comment:7 by , 11 years ago
Summary: | Closing window (and saving state) via keyboard causes abort on resume → Closing window (and saving state) via keyboard causes abort on resume => Fixed in SVN |
---|
A fix for the problem with the keyboard will be available with the next maintenance release. The monitor issue reported by Nigel could be a different problem.
comment:8 by , 11 years ago
Ah, frank, thanks! I ended up getting vbox sources, commenting out the offending line (PS2KProcessKeyEvent(pThis, u8, false /* key up */).
After a bit more playing around with it, it appears that if any key is depressed (save the host key) when the machine state is saved, on resume, it will fail to resume.