Custom Query (16363 matches)
Results (631 - 633 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #19060 | fixed | Bug in todo rescheduling in supR3HardenedWinVerifyCacheProcessWvtTodos() - fixed in SVN | ||
| Description |
Look at the source code here: in the function supR3HardenedWinVerifyCacheProcessWvtTodos(), I'm thinking the handling of the linked list for rescheduling is botched. For example, I see pReschedule initialized to NULL, but I don't see anywhere else in that method where it's assigned. Then near the end of the method, its value is checked, which would seem to be pointless since it's always going to be NULL. For context, see https://www.virtualbox.org/ticket/13659 |
|||
| #11289 | fixed | Closing window (and saving state) via keyboard causes abort on resume => Fixed in SVN | ||
| 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. |
|||
| #2404 | fixed | Guru meditation after forced using VT-x (restore raw mode state) | ||
| Description |
I turned on VT-x in one of my machines (SLES 10 SP2, if that matters) and had it running when started another machine from the saved state (which had VT-x disabled). Then I got a message about forced VT-x enabling for the second machine, agreed to it and the machine started normally. However, after I tried to go into it (no Guest Additions installed, so I had to perform a mouse click inside), I could not move the mouse, and in a couple of seconds the message about internal error appeared. Host OS: WinXP SP3 Pro Guest OS (the second one, which failed): WinXP SP3 Pro, no GA |
|||

