VBox Manager crashes when shutting VMs, accessibility zoom related (#17842)

[fth0]

---

ModEdit; related ticket: #17842: VirtualBox crashes while shutting down guest VM

---

I'm experiencing the same VirtualBox GUI crashes (nearly identical stack trace) since updating macOS (details see below). I've conducted some experiments to narrow down the cause of the crashes. I'm documenting my findings here in the hope they can contribute somehow.

0. Initial working setup (without VirtualBox GUI crashes):
A few weeks ago my setup consisted of an iMac15,1, macOS 10.12.6 Sierra, VirtualBox 5.2.20 and several VMs running different guests (macOS, Linux, Windows, ...) without any problems.

1. VirtualBox GUI crashes after updating macOS:
After updating my iMac to macOS 10.13.6 High Sierra, I've routinely checked my installed applications. I've been looking through the VirtualBox GUI app dialogs including the global VirtualBox settings, but do not remember changing anything (although I'm not 100% sure here). Since then the VirtualBox GUI crashes when powering off any VM with a (guessed) 80% chance. Uninstalling VirtualBox using the VirtualBox_Uninstall.tool and reinstalling did not help.

2. The VM is probably irrelevant:
The VirtualBox GUI crashes happen with all my VMs. To conduct some experiments I created a very simple VM (OS 'Other', no media, no CD, no Audio, no USB, ...) which can only boot up to INT 18h. Reproducing the crashes using this VM I collected several VBox.log files from runs with and without the crash, and they do not show any significant differences or difference patterns.

3. Detailed procedures of (not) reproducing the VirtualBox GUI crash:
I've been using the VirtualBox GUI ('GUI'), the VBoxManage CLI command ('CLI') and the VM ('VM') itself in various combinations to start and power off my test VM. These are my key findings:

a) Starting the VM: At the time the VM is started (GUI or CLI), the GUI must be already up and running, for the crash to occur later on when stopping the VM. When first starting the VM from the CLI and afterwards starting the GUI itself, the crash does not occur later on when stopping the VM.

b) Stopping the VM: At the time the VM is stopped (GUI, CLI or VM), the crash does not occur immediately, but when the GUI window is becoming the foreground window (either automatically or manually).

4. Additional bits:
I've checked the global configuration file VirtualBox.xml and the VBoxSVC.log files and did not find any additional hints.

[fth0]

Some weeks later I've analyzed the crash a bit further with the following new findings:

1. VirtualBox GUI versions 5.1, 5.2 and 6.0 each come with the cross-platform QT 5.6.3 graphics library. Part of QT is libqcocoa.dylib which connects the OS agnostic QT library with the macOS Cocoa API. The crash occurs inside the menu handling code which has known bugs in exactly the area the crash occurs in. Those bugs have been resolved in current versions of QT and I can provide links to information about that if desired. Unfortunately I'm not knowledgeable enough to replace the QT library in the VirtualBox app with a more recent version myself.

2. I also have identified a prerequisite necessary to either reproduce or avoid the crash: In my macOS installation the accessibility zoom function is enabled, and I sometimes enjoy using it to quickly enlarge some area of the screen for easier viewing. After logging in to macOS and before using the zoom function for the first time (unrelated to VirtualBox) the crash never happens. After having used the zoom function at least once the crash happens with at least 80% probability. Logging out and in again resets the prerequisite.

3. Combining everything with an educated guess: After the accessibility zoom function has been used for the first time, GUI apps get (or do not get) some (visible or hidden) automatic menu entries (like Edit/Dictate). Every time the GUI app becomes the foreground app, the macOS menu bar is updated and the menu delegate function (QCocoaMenuDelegate in the VirtualBox/QT case) has to handle this. The collaboration between the QCocoaMenu and NSMenu layers in QT 5.6.3 are buggy in this area (fixed multiple times in the last two years) and the QCocoaMenuDelegate is called with an already deleted menu entry when crashing. Alternatively the VirtualBox GUI app menu code may be buggy and updating a menu entry shortly after deleting it (race condition).

@socratis: Part of the information given in this and my previous post may be only useful for VirtualBox developers. Is this forum read by VirtualBox developers or can you provide them a hint to this information?

[socratis]

I split/moved your posts from the similarly titled thread that was in the "OSX pre-releases" section. You're not running a pre-release OSX version...

I'll edit your 3rd post to reflect the change and actually include the proper URLs.

[fth0]

@socratis:
I could need some help from an expert on how to proceed further. Since you're the good soul (I hope this is the appropriate English language term) of the macOS related VirtualBox forums, I'm turning to you. And I'm sorry in advance for another lengthy text of mine, please bear with me.

In the preceding weeks I've been analyzing the VirtualBox GUI crash from various different perspectives: First there are some VirtualBox forum threads and some VirtualBox tickets from the last two years, which exhibit the same crash, but did not lead to a real understanding and/or solution to the problem so far. Then there is some information spread across the internet which is (near or far) related to the crash (known and solved QT issues amongst them). Last but not least there are my findings, some of which I wrote down in two posts, that probably hardly anybody has read because of their length and complexity, which demands thorough reading. Despite the length the content is relatively precise, IMHO at least over 90% correct and could help understanding the crash.

I now see several paths to follow, but could need some help in any/all of them:

1. Reproducibility: For me the crash is now easy to reproduce, because I now know quite exactly how to do it. But we cannot be sure if this is the case for you (or others or even anyone). If you are able and willing to try, I can give you precise instructions, and the test should only take about 5 minutes. Are you interested?

2. Testing a newer QT version: An educated guess tells me that using a newer QT version could be enough to solve the crash (with a probability between 50% and 80%). Although I'm a developer (and hunter of complicated bugs and network security expert) myself, unfortunately I know very little about the macOS dynamic library plugin concept, the QT build concept and the VirtualBox build concept, and skimming the documentation about them leads me to think that it would take me at least some days of work (learning curve) to replace the QT library myself. Do you know anyone who can give me a hand with that?

3. VirtualBox ticket(s): I could add information to (one? of the) related existing tickets (e.g. #17842) or open an own ticket to add information about or links to the known (and solved) QT issues, but it takes some time to collect this information again. Do you think it's worth the effort (shall read: is there anyone going to evaluate the information and act upon it)?

Thanks in advance for your time and help!

fth0

[jeffpar]

I've looked at ticket #17842 (https://www.virtualbox.org/ticket/17842) and it appears to be identical to the crashing behavior that I've seen on macOS (Mojave) for a long time. I've lived with it for probably a year (even before Mojave), and I keep hoping that some new release of VirtualBox will fix the problem, but that hasn't happened yet.

Today I took the extra step of uninstalling VirtualBox and installing the latest test release, but... same exact crash. The crash usually occurs immediately after powering down any VM -- doesn't matter if it's an old VM or a newly created VM.

I occasionally use the "Zoom" accessibility feature, too, so I'll experiment with avoiding that feature and see if it makes any difference. Thanks.

[fth0]

@jeffpar: Thanks for your feedback.

VirtualBox 5.2.x and 6.0.x use the same (older) QT library version 5.6.3 on the macOS host (in contrast to VirtualBox on Linux hosts using the QT version accompanying the Linux distribution), so I wouldn't expect the problem to go away by using the current VirtualBox version.

Up to now, I didn't feel the urge to go through the hoops of building VirtualBox on macOS myself, and I suspect there will be more to do then to just replace the QT library and calling kmk.

I'm still monitoring this thread and I'm happy to read about anything confirming and/or contradicting my findings, so please keep me updated.

[nyholku]

Hi,

this is almost 100% reproducible on my Mac.

I have seen this problem on several macOS versions and several VirtualBox version.

Now I'm running 10.13.6 High Sierra on 2018 MacBook Pro with 32 GB RAM and just yesterday I updated to VirtualBox 6.0.8 r130520 (Qt5.6.3) to see if this has been fixed but no.

To reproduce this in my setup:

1) Start VirtualBox.app
2) Start a Powered Off Windows 10
3) Quit the Virtualbox VM that is running the Win10
4) After a few seconds the VirtualBox.app crashes

This does not seem to have any lasting or negative effect but is of course annoying.

cheers Kusti

PS Where is the bug reporting tool, Spotlight did not find it...

[socratis]

@nyholku
I moved your post from (the now locked) [Solved] crash after quitting vm. That thread was marked as [Solved], there's no point continuing on a 2018 thread, when there's this one dealing with the same issue.

this is almost 100% reproducible on my Mac.

I love reproducible issues. As long as we can find the culprit...

PS Where is the bug reporting tool, Spotlight did not find it...

What bug reporting tool? If you mean VirtualBox's bug reporting tool, Spotlight won't find it because it's inside an app bundle. And Spotlight is discrete, doesn't go into the inner of bundles. If you want something more powerful and GUI, see EasyFind from DEVONtechnologies.

Here's how you do it; Open a Terminal, type the command:

• 
  VBoxBugReport "<VMname>"

where "<VMname>" is the actual name of the VM that just crashed VirtualBox. This will generate a "YYYY-MM-DD-hh-mm-ss-bugreport.tgz" file in the current directory (most probably your home directory). Attach that file in your response. See the "Upload attachment" tab below the reply form.

And I'll need the output of another couple of commands:

• 
  kextstat | grep -v com.apple
  ls -ald /Applications/*/*

Either save that output in a text file, or post it as is inside a {code} tag.

[Ulik]

I hope I am not too daring if I post my files, because my problem is exactly the same. Only it is Win 7 VM.

Thank you

[Crispi]

NB. In order to differentiate issues, this thread is intended to be about how the manager crashes when VMs are closed, not the guests themselves crashing.

I've got Virtualbox 6.0.8 GUI still crashing each time a VM is closed. (eg when powering off).

Host : Mohave 10.14.5 (18F132)
Virtualbox : 6.0.8 with VBox Additions added
Guest : Any and all, as far as I can work out. But for example, a default VM is Windows 7 (64 bit), delete the hard disk, and press finish.
OS Guest : Immaterial (Could be a diskless machine even). If I just power it up and press F12 to go into the Boot screen, then power it off again, virtualbox will still quit
I'm running Virtualbox as a non-admin user.

NB, I've already uninstalled Virtualbox and reinstalled it again. No difference.

[Crispi]

Example of the output. (It SIGSEGVs):

Part 1:

[ModEdit: Raw copy/paste of partial log removed]

[Crispi]

Part 2:

[ModEdit: Raw copy/paste of partial log removed]

[Crispi]

Now here's an interesting thing.

If I run /Applications/VirtualBox.app/Contents/MacOS/VirtualBox as root, and follow the same steps (other than the location of the VM being different), the manager crash does not occur when the VM is powered off and the VM's window closed.

[Crispi]

Part 2:

[ModEdit: Raw copy/paste of partial log removed]

I can't paste the whole log. It won't accept more than 60000 characters.
I thought you wanted information????

[socratis]

You're rather eager to hit the "Post Reply" button, aren't you? Faster than a chat client...

I thought you wanted information????

Yes, we do, although an OSX crash report is not always useful to us commoners.

Please do not simply copy/paste huge chunks of text verbatim. Instead ZIP that file and attach that.