VirtualBox crashes while shutting down guest VM

[QA]

VirtualBox 5.2.12 crashes every time while shutting down any guest VM.

[QA]

macOS Problem Report for VirtualBox

[Dennis Schafroth]

Seeing a similar problem with 6.0.8.

[Socratis]

Related discussion in the forums: ​https://forums.virtualbox.org/viewtopic.php?f=8&t=93863

This ticket has been getting more and more attention. There are several reports of people getting affected. We've narrowed it down to the bug being triggered when using the Zoom Accessibility feature at least once after logging on.

The issue seems to affect:

• All Mac models tested.
• OSX ≥ 10.12 10.13
• Earliest VirtualBox tested: 5.2.12 (in this ticket).
• Latest VirtualBox tested: 6.0.10

I'm going to summarize the reports just to give you an idea:

• 2019-02-14: 10.12.6, VirtualBox 5.2.20, iMac15,1 (fth0) <<< Does not crash.
• 2019-07-17: 10.11.6, VirtualBox 6.0.10, MacBookPro11,5 (socratis) <<< Does not crash.
• 2019-07-23: 10.12.6, VirtualBox 6.0.10, MacBookPro8,3 (socratis) <<< Does not crash.

• 2018-06-27: 10.13.5, VirtualBox 5.2.12, MacBookPro14,3 (QA from #17842)
• 2019-02-14: 10.13.6, VirtualBox 5.2.20, iMac15,1 (fth0)
• 2019-06-07: 10.13.6, VirtualBox 6.0.8, MacBookPro15,1 (nyholku)
• 2019-06-16: 10.14.5, VirtualBox 5.2.30, MacBookPro12,1 (Ulik)
• 2019-07-13: 10.14.5, VirtualBox 6.0.8, ??? (Crispi)
• 2019-07-17: 10.14.5, VirtualBox 6.0.10, iMac18,3 (granada29)
• 2019-07-17: 10.13.6, VirtualBox 6.0.10, MacBookPro8,3 (socratis)

but for the full discussion, the crash reports, and the reason that user 'fth0' thinks that this gets triggered, you should really look at the discussion in the forums. As 'fth0' wrote:

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

EDIT
Edited to reflect the fact that OSX ≥ 10.13 is required for the bug to show.

[fth0]

While examining the crash in February 2019, I documented a lot of details in the thread linked by socratis above. Unfortunately, I did not save the links to the known bugs in QT 5.6.3 which I highly suspect being the cause of the crash. (There even has been a similar crash in the macOS version of a well-known, cross-platform browser app, if I remember correctly. ;) )

Investing one or two hours, I could collect the missing information again and write a short summary about it, and I'm willing to do so, if there is a developer interested in it ...

[gombara]

Replying to fth0:

While examining the crash in February 2019, I documented a lot of details in the thread linked by socratis above. Unfortunately, I did not save the links to the known bugs in QT 5.6.3 which I highly suspect being the cause of the crash. (There even has been a similar crash in the macOS version of a well-known, cross-platform browser app, if I remember correctly. ;) )

Investing one or two hours, I could collect the missing information again and write a short summary about it, and I'm willing to do so, if there is a developer interested in it ...

Any additional information would be appreciated as it would make us to address the problem faster.

[fth0]

Replying to gombara:

Any additional information would be appreciated as it would make us to address the problem faster.

Firstly, I assume that you've read my three initial posts in ​https://forums.virtualbox.org/viewtopic.php?f=8&t=93863. They contain several details about the necessary preconditions and an analysis of the sequence of events of the crash (from a black box testing perspective).

When researching the background of the crash (QCocoaMenuDelegate sending a message to an already destroyed NSMenuItem, possibly a race condition), I learned about a major design change in qcocoamenu.mm in QT 5.6.3 *1, which has led to problems in several mainstream software, and has been amended several times in QT versions 5.6.3 *2, 5.9 *3 and 5.12 *4. There are also several QT bugs linking to those commits, and even more commits *5.

1: ​https://github.com/qt/qtbase/commit/09acf326dbc6b7b67f21a360be8c91605ce47f1e

2: ​https://github.com/qt/qtbase/commit/56384a854aeaa5d3275c158c80a07082949468da

3: ​https://github.com/qt/qtbase/commit/385589ef458715fcaa533bbd01ca421dc1040eba

4: ​https://github.com/qt/qtbase/commit/e996c74164f6a161c030d3aff1348b1ef7f5da6f

5: ​https://github.com/qt/qtbase/commits/5.12.1/src/plugins/platforms/cocoa/qcocoamenu.mm

There is one additional timing detail I noticed only later: At the very end of any VBOX.log file there are several closing messages, amongst them one or two messages regarding a request to close the Runtime UI; they are usually within a very small time interval of a few ms. When the crash occurs, at least one of those messages is delayed by an additional 500 ms (this is a necessary but not sufficient condition).

EDIT: Clarified the last paragraph a bit.