Opened 10 years ago

Closed 9 years ago

#45169 closed defect (fixed)

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

Reported by: RJVB (René Bertin) Owned by: michaelld (Michael Dickens)
Priority: High Milestone:
Component: ports Version: 2.3.1
Keywords: haspatch Cc: mkae (Marko Käning)
Port: qt4-mac

Description

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.

Attachments (1)

prevent_addTitleRelated_crash.patch (425 bytes) - added by RJVB (René Bertin) 10 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to michaelld@…

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

comment:3 Changed 10 years ago by 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).

comment:4 Changed 10 years ago by 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.

comment:5 in reply to:  4 Changed 10 years ago by 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

Changed 10 years ago by RJVB (René Bertin)

comment:6 Changed 10 years ago by 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.

comment:7 in reply to:  3 Changed 10 years ago by 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 ....

comment:8 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:9 Changed 9 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

This is part of the 4.8.7 release. Closing ticket.

Note: See TracTickets for help on using tickets.