qt4-mac: prevent a crash when KDE apps use KMenu::addTitle

[RJVB (René Bertin)]

KDE4 applications can call a KDE4 function that is supposed to add a title item to a menu, rendered differently. This works on Linux and on OS X in popup menus, but not in menus that are part of the menubar. A very simple bug in Qt leads to a null pointer dereference and an immediate crash.

Attached is a patch for Qt 4.8 that prevents the crash. It does not make the KMenu::addTitle function have the intended effect (it remains invisible except perhaps the 1st time the menu is opened), nor does it prevent other potential related crashes.

[RJVB (René Bertin)]

NB: see ​https://git.reviewboard.kde.org/r/120355/ for in-depth discussion and an example work-around that emulates the addTitle function.

[ryandesign (Ryan Carsten Schmidt)]

Since this changes runtime behavior, the port's revision would need to be increased.

[michaelld (Michael Dickens)]

Do you know if this issue been reported to the Qt devs? I don't mind adding in a patch to MacPorts' Qt (we have lots), but for something of this consequence I'd expect a Qt ticket on the subject too. I'm going to be working on Qt4 in 10.10 soon (next week hopefully) and will add in this patch when I do that one (and others).

[RJVB (René Bertin)]

That's on my todo list, just haven't gotten around to it yet while I'm fiddling with KDE's addTitle function.

[RJVB (René Bertin)]

Replying to rjvbertin@…:

That's on my todo list, just haven't gotten around to it yet while I'm fiddling with KDE's addTitle function.

​https://bugreports.qt-project.org/browse/QTBUG-41716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel#comment-258898

[RJVB (René Bertin)]

I've simplified the patch; I think the change to isResize was overkill (the way it was done) and probably even lead to content not resizing when resizing windows.

In its simpler form, the patch only prevents the call to the function that requires q->parentWidget() != NULL; it presumes that widgets for which that condition isn't met will not have a buffer to invalidate.

[RJVB (René Bertin)]

Replying to michaelld@…:

I'm going to be working on Qt4 in 10.10 soon (next week hopefully) and will add in this patch when I do that one (and others).

Hi Michael:

Would you be interested in trying to combine that with a change in the way Qt4 is installed, in preparation for concurrent Qt4 and Qt5 installs, with qtchooser as a runtime means to pick one or the other where relevant (qmake for instance)?

I'd see this as follows

• install Qt4-mac to ${prefix}/lib/qt4
• put symlinks pointing to the required frameworks, libraries (and helper binaries?) in the places where they are installed currently
• ditto for Qt5-mac

The current exclusive install will make that symlink approach possible, which will in turn allow existing applications to function without rebuilding. Hopefully it will also ensure that port will not detect missing dependencies and trigger a rebuild of all Qt dependents. Newly built applications will refer to the new library/framework locations, making the approach even easier than it is on Linux.

qtchooser can then be set up to serve the selected install trees for Qt4 and Qt5 (tested separately of course), and once that works on bot Qt4 and Qt5 installs the symlink glue can be removed which ought to trigger a rebuild of all ports depending on Qt.

What do you think? I'm willing to test this for the current Qt4-mac port on my end, if you give me some pointers what to change where in that complicated portfile ....

[mkae (Marko Käning)]

Cc Me!

[michaelld (Michael Dickens)]

This is part of the 4.8.7 release. Closing ticket.