Bug 71657

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:
+