Bug 366596 - Some KDE applications processes remain as background (zombie) processes after closing
Summary: Some KDE applications processes remain as background (zombie) processes after...
Alias: None
Product: kde-windows
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Other Microsoft Windows
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: KDE-Windows
Depends on:
Reported: 2016-08-10 16:29 UTC by Jasem Mutlaq
Modified: 2021-07-09 18:49 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Jasem Mutlaq 2016-08-10 16:29:51 UTC
Using latest emerge with Qt 5.7 and Frameworks. Some applications (tested KStars & Kwrite) processes remain in the background _after_ you close them. I'm not sure what is causing this, perhaps if any applications that requires any KIO jobs or detached jobs is affected by the same behavior?

Reproducible: Always

Steps to Reproduce:
1. Launch kwrite.exe
2. Close kwrite
3. Open Windows task manager and kwrite.exe still exists in the processes tree

Actual Results:  
Process still remains in task manager

Expected Results:  
Process should be terminated

Just emerged kate with similar results.
Comment 1 Mateusz Mikuła 2016-08-20 19:45:18 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
Comment 2 Kevin Funk 2016-08-23 08:04:10 UTC
I'm on it.
Comment 4 Kevin Funk 2016-08-23 08:44:26 UTC
Comment 5 Mateusz Mikuła 2016-08-24 18:57:17 UTC
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:
int main() {
  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
Comment 6 Kevin Funk 2016-08-24 19:40:52 UTC
@Mateusz: I have another patch for kiconthemes which solves a similar hang-on-exit. Please stay tuned, I'll upstream the patch asap.
Comment 7 Jasem Mutlaq 2016-09-12 22:06:29 UTC
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?
Comment 8 Sven Brauch 2016-09-12 22:08:45 UTC
I think Kevin has patches, they just need to be upstreamed.
Comment 9 Jasem Mutlaq 2016-09-18 05:59:14 UTC
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?!
Comment 10 Sven Brauch 2016-10-18 18:16:23 UTC
Well, you can apply the 4 patches listed above, then it works. Regarding upstreaming them, I have no clue, sorry.
Comment 11 Mateusz Mikuła 2016-10-18 18:29:30 UTC
Apps freeze even with those 4 patches.
Comment 12 Jasem Mutlaq 2016-11-19 20:43:57 UTC
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?!!
Comment 13 Jasem Mutlaq 2016-11-24 17:56:53 UTC
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

Comment 14 Albert Vaca 2016-11-28 14:31:02 UTC
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
Comment 15 Kevin Funk 2016-11-29 10:23:46 UTC
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?
Comment 16 Albert Vaca 2016-11-29 10:51:37 UTC
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
Comment 17 Gleb Popov 2016-11-29 11:48:10 UTC
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.
Comment 18 Albert Vaca 2016-11-29 12:16:49 UTC
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...
Comment 19 Jasem Mutlaq 2016-11-29 12:20:30 UTC
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.
Comment 20 Kevin Funk 2016-11-29 13:16:13 UTC
> 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).
Comment 21 Jasem Mutlaq 2016-11-29 13:22:37 UTC
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.
Comment 22 Gleb Popov 2016-11-29 13:50:59 UTC
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.
Comment 23 Albert Vaca 2016-11-29 16:53:02 UTC
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.
Comment 24 Hannah von Reth 2016-11-30 10:48:04 UTC
- 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.
Comment 25 Kåre Särs 2016-11-30 11:11:15 UTC
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).
Comment 26 Albert Vaca 2016-11-30 16:42:55 UTC
(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.
Comment 27 Gleb Popov 2016-12-10 16:43:17 UTC
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?
Comment 28 Gleb Popov 2020-05-05 12:11:31 UTC
This seems to be not relevant anymore. I don't see any hangup dbus processes.