QAction::setFont leads to crash on OS X if font not found (or custom app font from resource)

This crashes (uncaught exception) right away on OSX:

#include <QApplication>
#include <QFont>
#include <QMenu>
#include <QAction>

int main(int argc, char *argv[])
{
	QApplication app(argc, argv);

	QFont font("Roboto", 11);
	QApplication::setFont(font);

	QAction action(0);
	font.setBold(true);
	action.setFont(font);

	QMenu menu;
	menu.addAction(&action);

	return 0; //app.exec();
}

The Roboto font is not installed on the system.
The real-world issue happened with the font coming from a Qt resource file and being set up with

QFontDatabase::addApplicationFont(":/Roboto-Regular.ttf")

However the same crash happens with unknown fonts, making the test case simpler.

The reason for the crash is this code in qcocoamenuitem.mm:

    NSFont *customMenuFont = [NSFont fontWithName:QCFString::toNSString(m_font.family())
                                  size:m_font.pointSize()];
    NSArray *keys = [NSArray arrayWithObjects:NSFontAttributeName, nil];
    NSArray *objects = [NSArray arrayWithObjects:customMenuFont, nil];
    NSDictionary *attributes = [NSDictionary dictionaryWithObjects:objects forKeys:keys];

The bug happens when customMenuFont is nil due to font not found, because then keys will have one item and objects will have zero items, and dictionaryWithObjects throws an exception when the two arrays don't have the same size.

I will submit a simple fix with a null pointer check, but it will only fix this crash by ignoring unknown fonts. The real-world bug will still exist, in the case where addFontDatabase was used with a font from a qt resource and therefore the font does actually exist - just not at the NSFont level. As far as I understand, QFontDatabase doesn't use that, but works with (higher levels?) APIs like CoreText and ATS. So maybe the real fix is to use these things here as well? But setAttributedTitle wants a NSFont, I guess...