| Summary: | Some KDE applications processes remain as background (zombie) processes after closing | ||
|---|---|---|---|
| Product: | kde-windows | Reporter: | Jasem Mutlaq <mutlaqja> |
| Component: | general | Assignee: | KDE-Windows <kde-windows> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | 6yearold, albertvaka, bugs.kde.org, faure, kare.sars, kfunk, mail, simonandric5, vonreth |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Jasem Mutlaq
2016-08-10 16:29:51 UTC
I'm porting KDE using MSYS2 (native building using mingw-w64). Instead of Emerge I've created PKGBUILD's (just like on Arch Linux) to build the stuff. KDE Framework apps are also affected. For an example kiconfinder5 from the KIconThemes is a small app (easier to work with) that is affected by this issue. It only hangs when arguments are provided, I did a small debugging and found out that it freezes when "return 0" or "return 1" is called. That led me to think it must be problem with resource freeing. More specifically if "const QString icon = KIconLoader::global()" is called the process will hang on return. kiconfinder5 code https://github.com/KDE/kiconthemes/blob/master/src/tools/kiconfinder/kiconfinder.cpp I'm on it. Related patches: https://phabricator.kde.org/D1909 https://phabricator.kde.org/D2142 https://phabricator.kde.org/D2545 Hi,
Kevin Funk maybe it's not related to KDE since I'm trying to "integrate" KDE with MSYS2 (could bebug with Qt, MinGW or whateber else).
I'm getting deadlock at return in every app that calls "KIconLoader::global()".
Minimal test case:
//includes...
int main() {
KIconLoader::global();
return 0; //freeze at this point
}
I've tried to use gdb with QtCreator but it didn't provide anything usefull (at least for me). How can I obtain more info about this deadlock?
Tools: CMake 3.6.1, MinGW-w64 6.1.0, Qt 5.6.1
@Mateusz: I have another patch for kiconthemes which solves a similar hang-on-exit. Please stay tuned, I'll upstream the patch asap. I just tested today and the issue is still there. So what's the plan here? Is this intended to be fixed in Qt or KDE or what? I think Kevin has patches, they just need to be upstreamed. well, any updates on this topic? We released a Windows version of KStars and users are complaining about this issue, the Windows port reception is critical but this bug is one of the many show stoppers. Is there anything I can do?! Well, you can apply the 4 patches listed above, then it works. Regarding upstreaming them, I have no clue, sorry. Apps freeze even with those 4 patches. I just emerged with Qt 5.8 and the bug is still there!! I first tried to emerge KStars and upon exist, kstars.exe still remains in the background. Then I emerged kate, and the exact same problem! I thought this was fixed in Qt 5.8?!! Git commit f38ff7cb890193cba6bcf8c50d48c7c9c22bd542 by Jasem Mutlaq. Committed on 24/11/2016 at 17:55. Pushed by mutlaqja into branch 'master'. Temporary hack to solve kstars.exe remaining in the background due to a big in Qt 5.8 that is not resolved yet M +12 -0 kstars/kstars.cpp https://commits.kde.org/kstars/f38ff7cb890193cba6bcf8c50d48c7c9c22bd542 Bump. This is still happening and Qt 5.8 doesn't solve it. What's blocking the fix? If we can't manage to solve it on the Qt side, we could at least apply the workaround patches ([1] and [2]) on our side. [1] https://phabricator.kde.org/D2546 [2] https://phabricator.kde.org/D2545 FYI: I stopped working on this issue because I don't fully understand why we get that hang on exit => thus don't know how to fix it properly either. Not even sure at what level to fix (Qt or KF5). The patches I posted work-around/fix the issue for KDevelop, though. I'm not sure where you got the impression that Qt 5.8 would fix the issue at hand, though. Source? In one of the bugs I linked before [1] David Faure mentions asking Thiago about it, to fix it in Qt. I don't know if there was any further conversation or an open bug in Qt, though, because I didn't find it. [1] https://phabricator.kde.org/D2546 Since this problem is present on Windows only, I'd rather continue with this plan: https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg34246.html Actually I have it on my TODO already, just haven't managed to work on this yet due to other stuff. Your plan is to drop DBus? IMHO, DBus is not an annoying dependency that we want to get rid of, is a useful tool for inter-proc communication. Mac and Windows have their own inter-proc communication mechanisms. Ideally on these platforms we would be using the tools they provide to achieve the same goals. Being realistic, though, I think it's a better solution to provide a DBus daemon and make it work on these platforms than just to kill every feature that requires inter-proc communication... Please do NOT drop DBus! KStars heavily relies of DBus for many things to work. If DBus is gone, we might as well not release for Windows/OSX altogether as it is not worth the effort. > Your plan is to drop DBus? IMHO, DBus is not an annoying dependency that we want to get rid of, is a useful tool for inter-proc communication.
... iff your application *depends* on having multiple processes around.
To all: If your application depends on DBus working properly on Windows, then this might be a good time starting fixing it in either layer (Qt5 or KF5).
DBus is already working under Windows and I tested it just fine with KStars, so why change anything? There are a couple of areas where it not having DBus would break functionality: Script Builder and Ekos Scheduler. The latter for example uses DBus to communicate with Ekos DBus interface and it was built on this very principle from the get-go so that other apps can also utilize the DBus interface to write their own apps. Point is, DBus is working fine now on Windows, and unless KF5 provides platform agnostic IPC that can abstracts this, then it is better leaving DBus as is. From what I know, the current course for KDE Apps on Windows is to have a separate installer for each App. This means that each app would have its own D-Bus stuff packaged in. I'm concerned of how these apps would coexist if installed together. Would they reuse a single D-Bus daemon, or run bundled ones? In the latter case there absolutely zero sense to have D-Bus on Windows. I'm also bugged by the fact that D-Bus processes keep running after app exits. And what I was talking about is not ripping D-Bus functionality off, but adding CMake options for frameworks in question to let them work without D-Bus. If your app really requires D-Bus, just build everything with that option turned to off. Running several dbus daemons will certainly cause problems and avoiding that is one of the challenges we will have to face. I personally think we should share certain components (like dbus and Qt) across apps. But that is a different discussion. But going back to my original point, this bug is still present and adding an option to build frameworks without DBus is not a fix for those who need DBus. - Running several versions of dbus should not cause an issue as dbus is configured to operate depending on its root directory. - Yes dbus will remain open when the application is closed. - Having a single dbus installation that is shared betwene all kde applications would be insane and impossible to maintain. - Dropping dbus would also mean dropping 90% of KDE's functionality. I compile Kate with the default Qt MSVC libraries from the online installer and I can not reproduce the problem with Kate. I have tried with both 5.6 and 5.7. I am running Windows 7 (have not tried on Windows 10 yet). (In reply to Hannah von Reth from comment #24) > - Running several versions of dbus should not cause an issue as dbus is > configured to operate depending on its root directory. DBus activation won't find the .service files if they are installed in an app's directory but the daemon running is running from a different app's directory. At least the .service files need to have a common path across apps. E.g.: KDE Connect needs dbus-activation, so it installs C:/Program Files/KDE Connect/share/dbus-1/services/org.kde.kdeconnect.service. If dbus-daemon is running from C:/Program Files/KStars, it will never find KDE Connect's .service file. Not sure if this is relevant, but here are my findings I **removed** all dbus files except dbus.dll and launched konversation. Upon exit it hanged on QDBusServiceWatcher destructor. Qt5Cored.dll!QWaitConditionPrivate::wait(QWaitConditionEvent * wce, unsigned long time) Line 119 C++ Qt5Cored.dll!QWaitCondition::wait(QMutex * mutex, unsigned long time) Line 184 C++ Qt5Cored.dll!QSemaphore::acquire(int n) Line 143 C++ Qt5Cored.dll!QMetaObject::activate(QObject * sender, int signalOffset, int local_signal_index, void * * argv) Line 3709 C++ Qt5Cored.dll!QMetaObject::activate(QObject * sender, const QMetaObject * m, int local_signal_index, void * * argv) Line 3603 C++ Qt5Cored.dll!QObject::destroyed(QObject * _t1) Line 217 C++ Qt5Cored.dll!QObject::~QObject() Line 920 C++ Qt5DBusd.dll!QDBusServiceWatcher::~QDBusServiceWatcher() Line 249 C++ KF5Notifications.dll!QDBusServiceWatcher::`scalar deleting destructor'(unsigned int) C++ Qt5Cored.dll!QObjectPrivate::deleteChildren() Line 1970 C++ Qt5Cored.dll!QObject::~QObject() Line 1041 C++ KF5Notifications.dll!KNotificationPlugin::~KNotificationPlugin() Line 34 C++ KF5Notifications.dll!NotifyByPopup::~NotifyByPopup() Line 220 C++ KF5Notifications.dll!NotifyByPopup::`scalar deleting destructor'(unsigned int) C++ Qt5Cored.dll!QObjectPrivate::deleteChildren() Line 1970 C++ Qt5Cored.dll!QObject::~QObject() Line 1041 C++ KF5Notifications.dll!KNotificationManager::~KNotificationManager() Line 118 C++ If there is no dbus daemon running, the watcher clearly shouldn't hang on waiting something, am I right? This seems to be not relevant anymore. I don't see any hangup dbus processes. |