Opened 8 years ago
Last modified 7 years ago
#16059 new defect
Unpaused hidden vms are crashing in i3-wm when removing host-screen
Reported by: | 1337 | Owned by: | |
---|---|---|---|
Component: | GUI | Version: | VirtualBox 5.1.6 |
Keywords: | Cc: | ||
Guest type: | all | Host type: | Linux |
Description
I'm running virtualbox on archlinux with the i3 window manager (all installed via pacman). Furthermore I'm working with two monitors on my host, thus using two screen outputs. Since updating virtualbox from version 5.0.22-1 to 5.1.6-1 (i3-wm stood in newest available verion 4.11-1) the following error was introduced:
If I store the virtual-guest GUI-representations in an tabbed i3-container (thus only the guest behind the active tab is displayed and the other ones are kept hidden behind their tabs) and remove one of my two outputs via „xrandr --output <OUTPUT> --off“, i3 (as always) starts to merge all workspaces to the remaining monitor. Unfortunately all vms which were awake and hidden behind a inactive (meaning not displayed) i3 tab are crashed afterwards.
The logfiles carry no information about the crashing reason, meaning both, the crashed and survived ones, whose which moved (or had to be moved) to another output and those which stayed (or should have stayed) on the remaining one, they all contain this lines in their logfile:
00:02:03.886456 GUI: UIMachineLogic: Host-screen count changed 00:02:04.014195 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary. 00:02:04.014233 GUI: UIMachineLogic: Host-screen available-area changed 00:02:04.045512 GUI: UIMachineLogic: Host-screen geometry changed 00:02:04.045641 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary. 00:02:04.045655 GUI: UIMachineLogic: Host-screen available-area changed
Is there a way to tune the logging amount for this purpose? Here is my output of
vboxmanage debugvm testvm show logdbg-settings Debug logger settings:
VBOX_LOG=all=0x0
VBOX_LOG_FLAGS=enabled unbuffered uself overwrite abs hex
One possible workaround is to pause all vms, another is to keep all vms visible on a focused workspace while removing one output. Furthermore while working with two monitors the workspaces can be moved between them without causing a crash of the hidden and unpaused vms.
This is a quite strange but easy reproducible behavior. For testing purposes I set up new vms without virtual HDs just running into BIOS-settings and they crashed too.
Could be related to: https://www.virtualbox.org/ticket/15863
Attachments (2)
Change History (7)
comment:2 by , 8 years ago
comment:3 by , 8 years ago
You did not include a log file for the virtual machine, could you please do that? If you can reproduce this with a distribution packaged version of virtual box with debug symbols (or a self-built one) please attach a back-trace of the crash with locals. Otherwise please try to get a core dump<1> which you can make available for upload (you can give me upload instructions at michael dot thayer at oracle) and possibly a back-trace too.
comment:4 by , 8 years ago
@Airblader : thx 4 your info
@michael: I'll attach a vm-logfile. Only the last 6 lines (which are already mentioned above) are generated when performing the described action.
It seams that the vm is running into segmentation fault:
[1] 1921 segmentation fault /usr/lib/virtualbox/VirtualBox -startvm test1
I'll also attach the coredump backtrace (hope I've done it right) and will compile vbox with debug symbols or upload the whole coredump later on.
comment:5 by , 8 years ago
Would it be possible for you to get a back-trace with symbols? If possible a "bt full" type. I see you are using a build which was not done by us, so a core dump file will not help us. Presumably Arch has some way, like Debian and Redhat variants, to install debug symbols for packages they provide.
comment:6 by , 7 years ago
Multi-monitor detach (see #16910 which xref a number of this type of issue) appears fixed in 5.1.24 Worth retesting since I suspect your xrandr detach/crash should be fixed as well
Just FYI, one difference between the focused window in a tabbed container and the others is that the others have _NET_WM_STATE_HIDDEN set. Perhaps VirtualBox uses this hint to save resources which ultimately causes the crash.