On Monday, 29 January 2018 11:32:56 CET René J.V. Bertin wrote: > Hi, > > Researching an issue I'm seeing (hang/crash on exit) I found the following > vestigial out-commented code the KCoreDirListerCache ctor in > kcoredirlister.cpp:
FYI: Note to the mailing list, before more precious developer time is being spent on this here: There are two more follow-up posts, just a few more hours younger, related to this issue on qt-interest: http://lists.qt-project.org/pipermail/interest/2018-January/029182.html (rather unrelated, but is also hinting at said problem...) http://lists.qt-project.org/pipermail/interest/2018-January/029194.html (asks about help for debugging crashes during destruction of QRegExpEngine) Regards, Kevin > // Probably not needed in KF5 anymore: > // The use of KUrl::url() in ~DirItem (sendSignal) crashes if the static > for QRegExpEngine got deleted already, // so we need to destroy the > KCoreDirListerCache before that. > //qAddPostRoutine(kDirListerCache.destroy); > > WHat's clear is that this no longer works: there is no `destroy` method in > whatever kDirListerCache's real class is. > > Git blame is of little help here; can anyone remember why the explicit > pro-active delete was deemed unnecessary, and what the exact symptoms were > when this was not done in KDE4? > > FWIW, the crash (or hang) happens during QRegExpEngine take-down when I have > used a KDE file dialog in a "pure Qt" application via a mechanism built on > code taken from the plasma integration plugin. It does not happen in KF5 > applications like kate or kdialog. As far as I know those applications > obtain the KDE file dialog from the platform plugin too. The difference > must be in the order in which certain things are deleted during the global > destruction phase, but which and how to restore the proper order. (The > Audacious audioplayer had a similar issue on exit in its Qt5 version, which > I traced to the QApplication instance being deleted via atexit; a lucky > shot in the dark that makes a lot of sense in retrospect.) > > Thanks for any pointers, > R. -- Kevin Funk | [email protected] | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
