By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2051 - Slow TDE logoff because a "gtk-qt-application" does not close correctly
Summary: Slow TDE logoff because a "gtk-qt-application" does not close correctly
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: amd64 Linux
: P5 minor
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2014-05-09 08:35 CDT by Francois Andriot
Modified: 2014-07-17 09:15 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Francois Andriot 2014-05-09 08:35:49 CDT 
Hello, this problem is happening on TDE 14.0.0 running on Mageia 4.

When using logoff (or poweroff or reboot...) from TDE session, I can see the TDE logoff window stuck on the first progress bar "Notifying application (gtk-qt-application)" (approximate english translation) during 20s.
I can wait 20s or I can press the "ignore notification" button.

Then I get a second progress bar, but it stucks again on "Closing application (gtk-qt-application)".
After 20 seconds (a timeout I guess), the session is finally closed.

I've tried killing manually all my GTK graphical applications that I could find BEFORE logoff, but I still get this mysterious "gtk-qt-application" that slows down the logoff. I cannot find which applications it is.

From what I understand, it is generic name for a GTK application using the gtk-qt engine.
How can I find out which application/process it really refers to ?

For now, I don't know if this is a bug in TDE or a bug in the application itself.
Comment 1 Timothy Pearson 2014-05-10 03:18:52 CDT 
I just updated the gtk-qt-engine code to properly report which application is stalling and/or crashing in GIT hash f824eb.  Hopefully once this lands in the nightly builds you will be able to more easily determine the source of the stall.
Comment 2 Timothy Pearson 2014-05-10 03:20:38 CDT 
(In reply to Timothy Pearson from comment #1)
> I just updated the gtk-qt-engine code to properly report which application
> is stalling and/or crashing in GIT hash f824eb.  Hopefully once this lands
> in the nightly builds you will be able to more easily determine the source
> of the stall.

Just noticed you are on Mageia, so you would have to wait for the Mageia maintainer to update the gtk-qt-engine packages.

Tim
Comment 3 Francois Andriot 2014-05-10 04:27:13 CDT 
OK thanks for the pactch, I've rebuilt for Mageia and I've found the culprit process:
the logoff popup says it's "notification-daemon-tde-gtk-qt-engine".

So the problem is in kdbusnotification.  But why does it use GTK at all ?
Comment 4 Timothy Pearson 2014-07-15 16:03:47 CDT 
(In reply to Francois Andriot from comment #3)
> OK thanks for the pactch, I've rebuilt for Mageia and I've found the culprit
> process:
> the logoff popup says it's "notification-daemon-tde-gtk-qt-engine".
> 
> So the problem is in kdbusnotification.  But why does it use GTK at all ?

Noticing this myself--not sure why it's hanging; I'll see what I can do to track it down.

The entire DBUS notification system is heavily Gnome/GTK-centric; in this case the library that interfaces with the notification system is GTK-based:
https://git.trinitydesktop.org/cgit/kdbusnotification/tree/src/daemon/daemon.cpp

Tim
Comment 5 Timothy Pearson 2014-07-17 09:15:51 CDT 
This should be fixed in GIT hash b1ed2b0.

Thanks for reporting!