VirtualBox

Opened 5 years ago

Last modified 5 years ago

#18361 new defect

VirtualBox 6.0.2 assertion failed while starting a macOS VM

Reported by: ilg Owned by:
Component: other Version: VirtualBox 6.0.2
Keywords: assert finder Cc:
Guest type: other Host type: Mac OS X

Description

My physical computer is a Mac Mini running macOS 10.13.6 and VirtualBox 5.2.2. Among several VMs I have, one is a macOS 10.10.

Today I tried to upgrade VirtualBox to 6.0.2, including the extpack, but when I tried to start the macOS VM, I got a meesage box with an error and the session did not start.

Checking the log, the only lines that seem to be related to VirtualBox are:

ilg-mini-harlescu:tmp ilg$ grep Virtual ~/Desktop/system.log
Jan 20 18:10:48 ilg-mini-harlescu VirtualBox[92143]: assertion failed: 17G4015: libxpc.dylib + 75013 [0BC7AD67-671D-31D4-8B88-C317B8379598]: 0x89
Jan 20 18:10:48 ilg-mini-harlescu VirtualBox[92143]: objc[92143]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fffa2078cd0) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x11caa6cd8). One of the two will be used. Which one is undefined.
Jan 20 18:11:24 ilg-mini-harlescu VirtualBox[92143]: BUG in libdispatch client: kevent[mach_recv] monitored resource vanished before the source cancel handler was invoked

Jan 20 18:20:52 ilg-mini-harlescu VirtualBox[914]: assertion failed: 17G4015: libxpc.dylib + 75013 [0BC7AD67-671D-31D4-8B88-C317B8379598]: 0x89
Jan 20 18:20:52 ilg-mini-harlescu VirtualBox[914]: objc[914]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff9413fcd0) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x1214becd8). One of the two will be used. Which one is undefined.
Jan 20 18:25:47 ilg-mini-harlescu VirtualBox[914]: BUG in libdispatch client: kevent[mach_recv] monitored resource vanished before the source cancel handler was invoked

I removed 6.0.2, reinstalled 5.2.22 and the same macOS VM started normally, so at least 6.x did not damage it.

My understanding of the log lines is that this new version of VirtualBox running on macOS has a problem and an assert is triggered.

The condition to have the class FIFinderSyncExtensionHost defined in two frameworks seems to be a known problem of macOS (https://stackoverflow.com/questions/46999695/class-fifindersyncextensionhost-is-implemented-in-both-warning-in-xcode-si), and I think it should not trigger the assert, the program should find a way to cope with this condition, as versions 5.x already did.

Change History (3)

comment:1 by Socratis, 5 years ago

Can't reproduce on a 2015 MBPr (MacBookPro11,5) with OSX 10.11.6 and VirtualBox 6.0.4.

BTW, it's usually better and faster, if issues get first addressed in the VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of, if the issue is resolved in the forums first.

comment:2 by ilg, 5 years ago

Can't reproduce on a 2015 MBPr (MacBookPro11,5) with OSX 10.11.6 and VirtualBox 6.0.4.

Did you check if those two frameworks are present on your system at the same time?

Since this is the problem, on some systems, for reasons known only by Apple, it is perfectly legal to have those two frameworks.

Unfortunatelly VB is more strict than necessary and this assert prevents it to run on such systems.

comment:3 by ilg, 5 years ago

I ran a new test with 6.0.4, and the behaviour was similar, the macOS 10.10 VM failed to start with the same error. The other VM available, an Ubuntu 17, started ok.

However I went further with the tests, I reinstalled 5.x and stopped the macOS VM which was currently suspeded.

Then I reinstalled 6.0.4 and the macOS VM started this time, but with a fresh reboot not from a suspended state.

The problem is less critical now, and will probably be considered an illegal use case (although the Ubuntu VM, suspended on 5.x had no problems to be resumed on 6.0).

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use