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

[Crispi]

More good news. It's not "root" related.

I can create a brand new non-root user in macOS and create and start Virtualbox VM, and the crashing issue also doesn't occur.

So it's something to do with my existing user's set up.

More narrowing down to do....

[Crispi]

More good news.

It's not anything to do with ~/Library/Preferences/org.virtualbox.app.VirtualBox* files
It IS something to do with one of the VMs in ~/VirtualBox\ VMs

I do have 39 VM images, so I'll try to work out if it's the number of VMs that I have, or whether there's a specific one that's giving issue.

I'll do a binary chop and see....

[socratis]

I do have 39 VM images, so I'll try to work out if it's the number of VMs that I have, or whether there's a specific one that's giving issue.

I can tell you for sure that it's not the number of VMs, I have 100...

[Crispi]

As far as I can see, it seems that the problem is not due to any one particular VM in the ~/Virtualbox VMs/ directory, but rather the number of VMs.

If I move more and more VMs into the directory from my '.orig' renamed directory [closing VBox each time before moving], then eventually there comes a point where the manager quits on VM exit.

So maybe there's a memory or file-handle issue?

My ulimits are as follows :

Code: Select all

deepthought:~ crispi$ ulimit -aH
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) unlimited
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 65532
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2128
virtual memory          (kbytes, -v) unlimited

deepthought:~ crispi$ ulimit -aS
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1418
virtual memory          (kbytes, -v) unlimited

[Crispi]

Nope. Setting soft limits to the same as hard didn't work.

I've run out of things to try. I'll attach the exception log.

[Crispi]

stacktrace.log.gz

stacktrace

(17.99 KiB) Downloaded 23 times

(gziped)

[fth0]

I happen to know your stack trace very well and can reproduce it easily.

Do you use any of the macOS accessibility functions (e.g. zoom, voice, ...) on your host?

If the answer is yes, then please login as your brand new non-root user, use the zoom function at least once, start your diskless VirtualBoxVM from within the VirtualBox GUI app and power it off. Repeat the VirtualBox VM start and power-off cycle five times. Does the crash now also happen on your new user account?

If the answer is again yes, you now know a method to prevent the crash from happening, and if you are interested in further details, you can read my own thread about this crash: viewtopic.php?f=8&t=91817

[Crispi]

Do you use any of the macOS accessibility functions (e.g. zoom, voice, ...) on your host?

Only control-double-finger swipe to zoom in occasionally.

If the answer is yes, then please login as your brand new non-root user, use the zoom function at least once, start your diskless VirtualBoxVM from within the VirtualBox GUI app and power it off. Repeat the VirtualBox VM start and power-off cycle five times. Does the crash now also happen on your new user account?

I'l try it now.

[Crispi]

If the answer is yes, then please login as your brand new non-root user, use the zoom function at least once, start your diskless VirtualBoxVM from within the VirtualBox GUI app and power it off. Repeat the VirtualBox VM start and power-off cycle five times. Does the crash now also happen on your new user account?

Wow. It crashed. It took 4 or 5 power on/off cycles. For a brand new user where all I did was enable the trackpad zoom function, create a diskless VM and start it.

Good work on narrowing it down to a reproducible issue.

[Crispi]

If the answer is again yes, you now know a method to prevent the crash from happening

On the regular account, I've disabled zoom, and restarted VBox. However, crashes still occur.

Actually I might try one more test - start TWO VMs and power off one, and see what happens.

[fth0]

If the answer is again yes, you now know a method to prevent the crash from happening

On the regular account, I've disabled zoom, and restarted VBox. However, crashes still occur.

In my experiments, having used the zoom function in my current macOS user session was the critical precondition for the crash. I had to log out of my user account (or reboot macOS) and log in again to prevent the crash from happening afterwards.

Did you log out of your regular account between disabling the zoom function and still crashing the VirtualBox GUI app?

After my experiments, I haven't disabled the zoom function and still use it occasionally. As long as I haven't used it since logging in, the crash never happens, so I can sort of live with this annoyance.

Also note that the crash is not necessarily related to the zoom function, but could be related to any accessibility function of macOS.

Actually I might try one more test - start TWO VMs and power off one, and see what happens.

The VirtualBox GUI app is one of many frontends for managing the VMs, and you can close it any time while VMs are running, without negative impact on the VMs. My expectation is that the second VM will still just be running after the crash.

[socratis]

Also note that the crash is not necessarily related to the zoom function, but could be related to any accessibility function of macOS.

Speaking of... check out this message in the 10.15beta thread "Virtualbox crashes when selecting another window". See if there's anything related in 10.14.5...

[fth0]

@Crispi: You should check out your settings in System Preferences -> Security & Privacy -> Privacy -> Input Monitoring, according to the linked post above (the one with the picture in it). But maybe there is no such category in macOS 10.14 Mojave ...

@socratis: Thank you for pointing out that thread. There could be a relation to our topic here, but at least it doesn't seem to fit to my crashes:

• First of all, the messages in that thread are all about VMs crashing and not the VirtualBox GUI app crashing (although some messages are inaccurate regarding this distinction).
• In my macOS 10.13.6 installation, there is no VirtualBox entry under System Preferences -> Security -> Privacy -> Accessibility, and there also is no Input Monitoring category next to it.
• I do not have macOS 10.14 Mojave running anywhere, but I think Input Monitoring is a new Security & Privacy category in macOS 10.15 Catalina.
• Probably I've just told you nothing that you didn't already know. So this post is for all other readers.

[socratis]

In my macOS 10.13.6 installation

Excellent! Now that you've told me exactly your OS version, I can definitely try and replicate your bug, I do have a 10.13.6 available, will boot from that. Will do it tomorrow and let you know what happened...

[fth0]

In my macOS 10.13.6 installation

Excellent! Now that you've told me exactly your OS version, I can definitely try and replicate your bug, I do have a 10.13.6 available, will boot from that. Will do it tomorrow and let you know what happened...

Thanks in advance for trying!
If you cannot replicate the bug within, lets say, 15 minutes, don't hesitate to ask for further details. Alternatively, ...


(I now have the feeling that I should apologize in advance.) Please do not take it personal that I cannot resist commenting on the following part of your statement:

Now that you've told me exactly your OS version, I can definitely try and replicate your bug

I already told you in my posts that you never found time to read in the past ([ModEdit; at the beginning of the merged now threads]). There you can find a lot of exact details regarding the reproducibility and the analysis of the crash (some of it written with a developer's background). If you would spend some minutes reading those posts, you probably would understand why I desperately tried to convince you to read them in the past.