virtualbox.org

VirtualBox 5.1.26, host OS macOS 10.12.6, 16GB RAM, guest OS Ubuntu 17.04 64 bits, 8GB RAM, guest additions installed. The guest is running headless, no X installed, used through SSH sessions from the host, runs CPU-intensive workload, and then aborts after ~10-20 hours of uptime. The log attached, but there is nothing written there at the time of abort, the last message is 18 minutes before the abort.

This started after upgrade to either 5.1.26, either 5.1.24, as one of the older VirtualBox versions was able to run the same for 5-7 days and completing without aborting. But the guest kernel has been updated meanwhile too, so I'm trying not to jump to conclusions too soon.

Has anybody encountered this? Is this a VBox/guest bug? Any workarounds? I'll downgrade now and re-test, but obviously this will take days.

Thanks,

Yes, it's a VirtualBox bug. And that's all that anyone can say without at least some diagnostic information. You might already have a crash log on your Mac. If so, please attach it.

The VBox.log file is useful but as you know, it has no information about the actual crash.

Yes I see there is a host crash log for VBoxHeadless process, must be that one. The GUI also tends to crash on close, but that would be VirtualBox process, right?

The crashing thread being "com.apple.audio.CADispatchQueue.SerialQueue", I wonder if unchecking "Enable Audio" (which I don't need anyway) in guest settings would help

Can you please try the latest available test build? It's available here: https://www.virtualbox.org/wiki/Testbuilds

Queued, a test with current version with audio disabled in the guest settings has already started, the test build will be one after that. (unless someone had the same crash, and disabling audio did not help?)

With audio disabled, 5.1.26 has been running for ~60 hours without crashing, it looks like it's a working workaround.

Unfortunately this is a laptop which I have to take on the road for the next three days, I will be able to test the test build with audio re-enabled only on Wednesday afternoon.

I've been having the same exact segfault and can confirm that 5.1.27 seems to have fixed it.

I have spent several days testing 5.1.27-117470 test build, with audio re-enabled in VM setting and the crash did not reproduce.