Version: (using KDE Devel) Installed from: Compiled sources To reproduce: - Start Kopete (tested starting from a konsole). - Sign on to some account (tested with AIM and IRC). - Open a chat with somebody. - Choose File --> Quit from the contact list window. - Note that there is now a Kopete process or two still running. This prevents Kopete from being restarted, as you must first kill off the old processes. What should happen: Kopete should quit when you tell it to ;-).
A typical example: kopete (irc - raw protocol): idx: 19 kopete (irc - raw protocol): << Using codec UTF-8 << ERROR :Closing Link: sigthor (Client Quit) kopete (irc): Unknown IRC command for line:ERROR :Closing Link: sigthor (Client Quit) kopete (irc): [void KIRC::slotConnectionClosed()] Connection Closed - local status: 4 sock status: 400 kopete (irc): [virtual void IRCChannelContact::updateStatus()] for:#lfs kopete (irc): [virtual KIRC::~KIRC()] irc.linuxfromscratch.org kopete (irc): [void KIRC::slotConnectionClosed()] Connection Closed - local status: 0 sock status: 400 libkopete: [void KopeteAccountManager::unregisterAccount(KopeteAccount*)] Unregistering account sigthor@irc.linuxfromscratch.org:6667 kutils (KSettings::Dispatcher): [void KSettings::Dispatcher::unregisterInstance(QObject*)] libkopete: [void KopetePluginManager::slotShutdownDone()] user sigthor@eirny:/home/sigthor $ ps -fAHwww Sgt | grep kopete sigthor 17926 1 2 03:15 pts/1 S 0:02 kopete Sometimes there is a child process also named kopete, sometimes not. I don't know why there is when there is.
Subject: Re: [Kopete-devel] New: Kopete process(es) stay running if you quite while a chatwindow is open On Friday 02 January 2004 09:21, Casey Allen Shobe wrote: > This prevents Kopete from being restarted, as you must first kill off the > old processes. Or press ctrl-c on the console from which you started Kopete if you were smart enough to run kopete --nofork ;-)
> Or press ctrl-c on the console I don't call this a fix, not even a workaround. I think you will have to find something else :-D
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Friday 02 January 2004 13:41, Olivier Goffart wrote: > I don't call this a fix, not even a workaround. I think you will have to > find something else :-D That's why I sent it to the list and not to Bugzilla, but now I have to add the noise here :(
Note also that these processes suck CPU like mad (99% on my system). And you can still reproduce with --nofork, it just hangs until you ctrl+c. The systray remains visible but does not respond to mouse input. This bug has been going on for at least a month here.
> That's why I sent it to the list and not to Bugzilla, but now I have to add > the noise here :( If indeed you think so, I believe you made a mistake and are wrong, as Comment #2 would indicate :P > Note also that these processes suck CPU like mad (99% on my system). Nope, they don't use any noticeable CPU here. > The systray remains visible but does not respond to mouse input. Nope, the systray goes away fine here. Only the processes remain.
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Saturday 03 January 2004 03:18, Casey Allen Shobe wrote: > > That's why I sent it to the list and not to Bugzilla, but now I have to > > add the noise here :( > > If indeed you think so, I believe you made a mistake and are wrong, as > Comment #2 would indicate :P Yeah, Olivier already told me that :( > > Note also that these processes suck CPU like mad (99% on my system). > > Nope, they don't use any noticeable CPU here. > > > The systray remains visible but does not respond to mouse input. > > Nope, the systray goes away fine here. Only the processes remain. Both of you are right, since this may or may not happen depending on how long the event loop was functional before it stopped working. The open window messes up the event loop and thus the rest of Kopete's shutdown process. The solution is to close the open chat windows just prior to unloading an account, but I'm not sure if there's a way to enumerate all windows per account. I'll try to come up with a patch.
would this problem go away if we made the chatwindow back into a regular class? At the time when the chatwindow was made a plugin, it didn't sound so bad, but i don't think it'll be useful anymore because of bugs like these and also if we decide to make the contactlist a kpart (which we would then, more than likely, want the chatwindow to be a part of the kpart rather than it's own seperate thing. oh, and also a long way off) My thinking is that then the chatwindow becomes part of the main event loop and is unloaded correctly.
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On January 03, 2004 09:39 am, Martijn Klingens wrote: > The solution is to close the open chat windows just prior to unloading an > account, but I'm not sure if there's a way to enumerate all windows per > account. I'll try to come up with a patch. - Enumerate account's contacts - - if( contact->manager(false) && contact->manager()->view(false) ) { contact->manager()->view()->closeView( true ); }
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Saturday 03 January 2004 16:00, Matt Rogers wrote: > would this problem go away if we made the chatwindow back into a > regular class? Not necessarily. Although I very much would like to see that happen from a simplicity point of view (why would we want different chatwindows ever?) it has little to do with this bug. > My thinking is that then the chatwindow becomes part of the main event loop > and is unloaded correctly. Please read up on event loops since there is only one event loop ;-) Event loops can be nested due to processEvents() or similar code, but they'd still be 'overall' event loops and not limited to a single plugin. There ain't no such thing as per-plugin event loops :) As for Jason's code snippet: thanks! It also points out the most horrific abuse of bools in an API that I've ever seen ;-) All three bools should be enums for decently readable code.
Created attachment 3976 [details] Fix quit with open windows Works for me (tm), please review. Martijn
Created attachment 3977 [details] What the heck did bugzilla do with my diff?!? Grmbl, new try.
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open Sunday 04 January 2004 17:31 > Works for me (tm), please review. Applied. Doesn't fix the problem for me. Tested using an IRC channel.
I don't think it's the right fix. Every chat view are already closed when the chatwindow plugin is unloaded But what's the problem in fact? Why does kopete not exit?
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Monday 05 January 2004 13:22, Olivier Goffart wrote: > I don't think it's the right fix. > Every chat view are already closed when the chatwindow plugin is unloaded Well, you call closeView() when unloading the chatwindow plugin and that for sure is broken. The accounts are already deleted when chatwindow is unloaded, so you're accessing a dangling pointer. Casey, does it work with other protocols for you?
Subject: Re: Kopete process(es) stay running if you quite while a chatwindow is open Monday 05 January 2004 07:49 > Casey, does it work with other protocols for you? Nope. Reproduced the hang with AIM as well. Does it work for you? Maybe I misapplied or something stupid...
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Monday 05 January 2004 22:36, Casey Allen Shobe wrote: > Nope. Reproduced the hang with AIM as well. Does it work for you? Yes, obviously, or I wouldn't have said 'works for me' :) (With MSN, that is, and quitting by right clicking the tray icon and selecting quit, if any of that matters.)
if this is the only bug we fix in KDE_3_2_BRANCH before release, this will make me happy. :/
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Sunday 18 January 2004 04:50, Matt Rogers wrote: > if this is the only bug we fix in KDE_3_2_BRANCH before release, > this will make me happy. :/ Works here. But I have a ton of uncommitted changes locally, so perhaps my proposed fix never went in?
Hmm, it works here indeed... for MSN. With Jabber I can reliably reproduce the problem, with MSN it always works. Jabber does something that MSN does not, but what? Martijn
I can reproduce this with just ICQ connected and one chatwindow open. attaching gdb to the process (shows as stopped in ps auxw output) gives: #1 0x412b769b in QEventLoop::processEvents(unsigned) () from /home/stefan/src/kde-cvs/qt-copy/lib/libqt-mt.so.3 #2 0x4131c478 in QEventLoop::enterLoop() () from /home/stefan/src/kde-cvs/qt-copy/lib/libqt-mt.so.3 #3 0x4131c328 in QEventLoop::exec() () from /home/stefan/src/kde-cvs/qt-copy/lib/libqt-mt.so.3 #4 0x4130a031 in QApplication::exec() () from /home/stefan/src/kde-cvs/qt-copy/lib/libqt-mt.so.3 Boring qt event loop :P
With no chatwin open it exits cleanly and debug output ends with: libkopete: [void KopetePluginManager::slotShutdownDone()] kopete: [virtual Kopete::~Kopete()] In case it hangs ~Kopete does not get called.
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Sunday 18 January 2004 16:05, Stefan Gehn wrote: > Boring qt event loop :P Yeah, it's stuck in an empty event loop doing nothing. But not so with MSN. I'm comparing the debug output with one MSN window open with that of one Jabber window, but to no avail :( Now rebuilding KApplication with debug output for the ref()/deref() calls enabled. See what that gives.
And another one: It has NOTHING to do with protocols! I can reproduce it with no protocols connected but one chatwindow open (weird anyway, why can I open a chatwindow although I cannot send anything?).
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open On Sunday 18 January 2004 16:10, Stefan Gehn wrote: > And another one: > > It has NOTHING to do with protocols! It has in that it works with MSN. I have the impression that MSN closes its windows sooner though. I just confirmed my suspicion, the refcount keeps stuck at 1 with Jabber when it's 0 with MSN. Somehow with Jabber KApplication thinks there are still KMainWindows around. Now adding debug output to the KopeteWindow dtor, see what that gives. > (weird anyway, why can I open a chatwindow although I cannot send > anything?). Fixed in HEAD.
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open Interestingly, with Jabber I get -------- kparts: MainWindow::createGUI, part=(nil) kparts: MainWindow::createGUI, part=0x8312a28 KopeteRichTextEditPart kopeterichtexteditpart kopete: KApplication::ref() : refCount = 3 kopete: KApplication::ref() : refCount = 4 kopete: KApplication::deref() : refCount = 3 kopete: KApplication::deref() : refCount = 2 libkopete: [virtual void KopeteSystemTray::contextMenuAboutToShow(KPopupMenu*)] Called. kopete: [void Kopete::quitKopete()] libkopete: [void KopeteAccountManager::save()] libkopete: [void KopetePluginManager::shutdown()] -------- Note the ref() and deref() calls in KApplication. With MSN I get -------- kparts: MainWindow::createGUI, part=(nil) kparts: MainWindow::createGUI, part=0x83126a0 KopeteRichTextEditPart kopeterichtexteditpart libkopete: [virtual void KopeteSystemTray::contextMenuAboutToShow(KPopupMenu*)] Called. kopete: [void Kopete::quitKopete()] libkopete: [void KopeteAccountManager::save()] libkopete: [void KopetePluginManager::shutdown()] -------- (After stripping non-relevant MSN debug output.) I wonder what's reffing in Jabber and if it is related. Oscar (ICQ) output is identical to Jabber. WTF is MSN doing different?
Subject: Re: [Kopete-devel] Kopete process(es) stay running if you quite while a chatwindow is open > I wonder what's reffing in Jabber and if it is related. It's not related. I added a kdBacktrace to the ref call in KApplication and it's two KIO jobs that ref and deref in ICQ and Jabber. Not that I have any idea what they're doing there, but it doesn't look related to me. Back to square one :(
The fact that MSN has it's own message manager probably has something to do with this. None of the other protocols have one (AFAIK).
> The fact that MSN has it's own message manager probably has something to > do with this. Nope, I can reproduce this easily (i.e. always) with an open oscar chatwindow.
Subject: Re: Kopete process(es) stay running if you quit while a chatwindow is open On Thursday 05 February 2004 11:01 am, Stefan Gehn wrote: > > The fact that MSN has it's own message manager probably has something to > > do with this. > > Nope, I can reproduce this easily (i.e. always) with an open oscar But the point is that this *doesn't* happen with MSN. So looking at what MSN does differently could provide clues...
yes, that's what i meant, and my speculation was that it didn't happen with MSN because MSN has it's own message manager. Apologies for not being more clear.
It seems to be happening for me with the 3.2 packages for Slackware 9.1, even with MSN. Steps to reproduce: 1) Open an MSN chat window 2) File->quit When I check System Guard/top, Kopete still appears to be running in the background.
Subject: kdenetwork/kopete/kopete/chatwindow CVS commit by mklingens: Forward port the 'Kopete doesn't close' bug fix. CCMAIL: 71657-done@bugs.kde.org M +17 -11 kopetechatwindow.cpp 1.67 M +6 -3 kopetechatwindow.h 1.22 --- kdenetwork/kopete/kopete/chatwindow/kopetechatwindow.cpp #1.66:1.67 @@ -5,7 +5,7 @@ Copyright (C) 2002 by James Grant Copyright (c) 2002 by Stefan Gehn <metz AT gehn.net> - Copyright (c) 2002-2003 by Martijn Klingens <klingens@kde.org> + Copyright (c) 2002-2004 by Martijn Klingens <klingens@kde.org> - Kopete (c) 2002-2003 by the Kopete developers <kopete-devel@kde.org> + Kopete (c) 2002-2004 by the Kopete developers <kopete-devel@kde.org> ************************************************************************* @@ -1105,12 +1105,22 @@ void KopeteChatWindow::closeEvent( QClos // if the view is closed, it is removed from chatViewList for us - if( !view->closeView() ) + if ( !view->closeView() ) + { + kdDebug() << k_funcinfo << "Closing view failed!" << endl; canClose = false; } + } - if( canClose ) - e->accept(); + if ( canClose ) + { + // Call the parent class's closeEvent, which will accept() the event, + // but also make sure that we deref() KApplication if we're the last + // open window + KParts::MainWindow::closeEvent( e ); + } else + { e->ignore(); + } } @@ -1155,10 +1165,6 @@ void KopeteChatWindow::slotConfToolbar() } -bool KopeteChatWindow::queryExit() -{ -// never quit kopete - return false; -} - #include "kopetechatwindow.moc" + // vim: set noet ts=4 sts=4 sw=4: + --- kdenetwork/kopete/kopete/chatwindow/kopetechatwindow.h #1.21:1.22 @@ -3,6 +3,7 @@ Copyright (c) 2002 by Olivier Goffart <ogoffart@tiscalinet.be> + Copyright (c) 2004 by Martijn Klingens <klingens@kde.org> - Kopete (c) 2002 by the Kopete developers <kopete-devel@kde.org> + Kopete (c) 2002-2004 by the Kopete developers <kopete-devel@kde.org> ************************************************************************* @@ -206,5 +207,4 @@ private slots: protected: virtual void closeEvent( QCloseEvent *e ); - virtual bool queryExit( ); virtual void windowActivationChange(bool); virtual bool eventFilter( QObject *o, QEvent *e ); @@ -212,2 +212,5 @@ protected: #endif + +// vim: set noet ts=4 sts=4 sw=4: +