VirtualBox

Ticket #16059 (new defect)

Opened 3 years ago

Last modified 2 years ago

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

VBox.log Download (54.9 KB) - added by 1337 3 years ago.
Log of a crashed vm
coredumpBacktrace Download (2.7 KB) - added by 1337 3 years ago.
Backtrace of coredump

Change History

comment:2 Changed 3 years ago by Airblader

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.

comment:3 Changed 3 years ago by michael

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.

<1> https://www.virtualbox.org/wiki/Core_dump

comment:4 Changed 3 years ago by 1337

@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.

Last edited 3 years ago by 1337 (previous) (diff)

Changed 3 years ago by 1337

Log of a crashed vm

Changed 3 years ago by 1337

Backtrace of coredump

comment:5 Changed 3 years ago by michael

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 Changed 2 years ago by simonc

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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use