Bug 62669

Just now it happend and the disk activity did stop after a while and the chat window does appear 
at last. Don't know how long it took though. 

Not enough information to find any cause for this, somebody experiencing this 
should watch memory usage very closely. 
Also try running it in gdb and stop it while it eats memory and then get a 
backtrace. 
Other than that I'm pretty sure this is not related to kopete (never ever seen this) 
but the usual RH flakyness. 

can you check and make sure that it happens with MSN also? I want to make sure 
it's not a protocol specific bug.

Yes, I can confirm that it happens also on MSN. Has happend I better say because the 
frequency droped dramatically. Last week it only happened once. I tried running from gdb but 
found myself unable to interrupt the process due to the freeze of the gui as described. Potential 
reasons why it does not occur so much anymore: I keep compiling cvs version from time to 
time; also I moved from kernel kernel-2.4.20-19.9 to kernel-2.4.20-20.9. 

Subject: Re: [Kopete-devel]   KDE frequently hangs due to high disk activity when opening chat session

High disk activity... swap file usage? Is memory low at the moment it occurs? 
Is Kopete seemingly leaking memory at that point?

Not that retrieving the RSS size and other memory usage statistics in Linux 
are highly unreliable for 2.4.x kernels. If you want to do some stats it 
might work to compare sizes directly after startup with those later on, but 
likely you'll need valgrind in leakcheck mode.

Interesting... I don't know if what I just experienced last night is related to
this bug or not, but I was using Kopete 0.7.1 on a SuSE 8.2 system (KDE 3.1.3)
and experienced high disk activity and nonexistent UI responsiveness on two
occasions.

I was logged into MSN, ICQ, and Yahoo at the time and was chatting on ICQ.  Both
times when the crash occurred, I was pasting some data from another window (a
command-line dump from a traceroute).  When I went to edit the message, the user
interface suddenly seemed to be running from swap (the disk thrashed badly and
everything was extremely slow).  This happened twice; both times I had tried to
paste and edit the same data to an ICQ contact.  The first time I became
impatient and reset the computer :-) and the second time the kernel ended up
terminating processes for me.

I just noticed that 0.7.2 has come out now (woohoo!!), so when I get a chance
I'll give that a try.

Oh, I had installed 0.7.1 from a SuSE rpm and my kernel is the latest 2.4.20-4GB
from SuSE.
Thanks!
Darryl

Subject: Re: [Kopete-devel]   KDE frequently hangs due to high disk activity when opening chat session

On Wednesday 10 September 2003 23:21, Darryl Millette wrote:
> I just noticed that 0.7.2 has come out now (woohoo!!), so when I get a
> chance I'll give that a try.

I doubt it will fix the problem though, as we haven't been able to pinpoint 
the cause yet :(

Actually, i have bad new concerning that. Previously i was using 0.7.9cvs from 20030812 or 
later. On that version it did hardly occur (only once). Today I installed a new computer on 
which I compiled the 0.7.2 release. It happend immidiately again. 
 
My computers are now in a network and i was able to ssh to the computer to find out that X 
was claiming about 81Mb and rising steadily. Maybe I will finally be able to attach gdb and get 
some more info on what is goining on internally. 
 
I'll let you know as soon as I find out more. 

0.7.x codebase is way older than what we have in CVS HEAD, that's why it#s worse 
in 0.7.x versions. 

I'm starting to wonder if this is related to the history plugin issue somebody else was having. There's a report filed, but I don't remember the bug number. How many of you are using the History plugin?

I am using the history plugin.

There is something else. When I compile from CVS, I must alter two lines of code to make it compile. I make the following alterations:

diff -r1.53 kopetemetacontactlvi.cpp
196c196
<                       KNotifyClient::event(winId, "kopete_offline", text );
---
>                       KNotifyClient::event("kopete_offline", text );

diff -r1.182 kopetemessagemanager.cpp
204c204
<                       KNotifyClient::event( 0 , QString::fromLatin1( "kopete_outgoing" ), i18n( "Outgoing Message Sent" ) );
---
>                       KNotifyClient::event( QString::fromLatin1( "kopete_outgoing" ), i18n( "Outgoing Message Sent" ) );

I don't know if this is related and how to fix that.

Subject: Re: [Kopete-devel]  KDE frequently hangs due to high disk activity when opening chat session

On Thursday 16 October 2003 08:36, Sebastiaan Ubink wrote:
> There is something else. When I compile from CVS, I must alter two lines of 
code to make it compile. I make the following alterations:

This is needed on KDE 3.1.0 only, 3.1.1 and newer have this new method. 
Someone pointed it out to me 2 days ago but I didn't check if this is the 
only occurrence of the problem, so I didn't commit a patch yet.

Do you need to patch more or just this?

(BTW, it's unrelated, but still needs fixing.)

Okay, clear ;) No, normaly I only need to patch these two lines.  Fortunately (or unfortunately) it does not happen so much...but is does from time to time). It seems I can attach gdb via my network now...maybe will be able to get that backtrace.

Subject: kdenetwork/kopete

CVS commit by mklingens: 

Fix compile for KDE 3.1.0 (e.g. stock RedHat 9.0)

Based on patch from Sebastiaan Ubink <ubink@xs4all.nl>

Also some minor changes and cleanups.

CCMAIL: 62669@bugs.kde.org


  M +14 -6     kopete/contactlist/kopetemetacontactlvi.cpp   1.55
  M +10 -2     libkopete/kopetemessagemanager.cpp   1.184


--- kdenetwork/kopete/kopete/contactlist/kopetemetacontactlvi.cpp  #1.54:1.55
@@ -185,10 +185,18 @@ void KopeteMetaContactLVI::slotContactSt
                 QString text = i18n( "%2 is now %1!" ).arg( m_metaContact->statusString() ).arg( m_metaContact->displayName() );
 
+                // Using the define is a bit hacky, but saves a ton of code duplication.
+                // FIXME: Remove ASAP once we drop KDE 3.1.0 support ;-) - Martijn
+#if KDE_IS_VERSION( 3, 1, 1 )
+#define WIN_ID winId,
+#else
+#define WIN_ID
+#endif
                 if ( m_metaContact->isOnline()  && m_oldStatus == KopeteOnlineStatus::Offline )
-                        KNotifyClient::event( winId, "kopete_online", text, i18n( "Chat" ), this, SLOT( execute() ) );
+                        KNotifyClient::event( WIN_ID "kopete_online", text, i18n( "Chat" ), this, SLOT( execute() ) );
                 else if ( !m_metaContact->isOnline() && m_oldStatus != KopeteOnlineStatus::Offline && m_oldStatus != KopeteOnlineStatus::Unknown  )
-                        KNotifyClient::event( winId, "kopete_offline", text );
+                        KNotifyClient::event( WIN_ID "kopete_offline", text );
                 else if ( m_oldStatus != KopeteOnlineStatus::Unknown )
-                        KNotifyClient::event( winId, "kopete_status_change", text, i18n( "Chat" ), this, SLOT( execute() ) );
+                        KNotifyClient::event( WIN_ID "kopete_status_change", text, i18n( "Chat" ), this, SLOT( execute() ) );
+#undef WIN_ID
 
                 if ( !mBlinkTimer->isActive() &&
@@ -580,5 +588,5 @@ void KopeteMetaContactLVI::slotBlink()
 }
 
-void KopeteMetaContactLVI::slotEventDone( KopeteEvent *event )
+void KopeteMetaContactLVI::slotEventDone( KopeteEvent * /* event */ )
 {
         m_event = 0L;

--- kdenetwork/kopete/libkopete/kopetemessagemanager.cpp  #1.183:1.184
@@ -26,8 +26,8 @@
 
 #include <kdebug.h>
+#include <kdeversion.h>
 #include <kglobal.h>
 #include <klocale.h>
 #include <kmessagebox.h>
-#include <kopetenotifyclient.h>
 
 #include "kopeteaccount.h"
@@ -35,9 +35,11 @@
 #include "kopetemessagemanagerfactory.h"
 #include "kopetemetacontact.h"
+#include "kopetenotifyclient.h"
 #include "kopeteprefs.h"
 #include "kopeteview.h"
 
-struct KMMPrivate
+class KMMPrivate
 {
+public:
         KopeteContactPtrList mContactList;
         const KopeteContact *mUser;
@@ -202,5 +204,11 @@ void KopeteMessageManager::sendMessage( 
                 emit messageSent( sentMessage, this );
                 if ( !account()->isAway() || KopetePrefs::prefs()->soundIfAway() )
+                {
+#if KDE_IS_VERSION( 3, 1, 1 )
                         KNotifyClient::event( 0, QString::fromLatin1( "kopete_outgoing" ), i18n( "Outgoing Message Sent" ) );
+#else
+                        KNotifyClient::event( QString::fromLatin1( "kopete_outgoing" ), i18n( "Outgoing Message Sent" ) );
+#endif
+                }
         }
         else

Considering the recent revelations of the performance of the history plugin wouldn't #65982 be a dupe of this message (or the other way around)?

I don't know, but I see a few striking differences. First the problem described here only occurs when opening a new and empty chat window. In #65982 they are talking about new messages comming in in an already openend window filled with messages. Also it seems in #65982 it occurs all the time while here it happens only occasionaly. E.g. I can not predict when it will happen.

My problem could very well be related to somthing else than Kopete, although i only see it when using Kopete so I don't know.

The 'hang' occurs when opening the chat window. At that moment the frame of the chat window is already on screen but the content (the two big edit boxes) are still grey, not painted white yet. Disk activity starts and usualy take up to something between 5-10 minutes on my AMD2600+/1Ghz DDR machine. X will use about 800Mb or so in the process. Eventualy it comes back and finishes painting the chat window. The 800Mb is released (takes a while) and everything is normal again.

I have a backtrace now and will post that in the following message.

This is captured after attaching gdb to the kopete process from a remote machine (over ssh). I hope this helps.

 bt
#0  0xffffe002 in ?? ()
#1  0x413fea07 in _XRead () from /usr/X11R6/lib/libX11.so.6
#2  0x413ff54d in _XReply () from /usr/X11R6/lib/libX11.so.6
#3  0x413f5acf in XQueryTree () from /usr/X11R6/lib/libX11.so.6
#4  0x40f0219c in QWidget::updateFrameStrut() const ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#5  0x40fb831d in QWidget::x() const () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#6  0x40f006c1 in QWidget::stackUnder(QWidget*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#7  0x40f0108f in QWidget::setMinimumSize(int, int) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#8  0x40f219a0 in QLayout::activate() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#9  0x40f20e28 in QLayout::eventFilter(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x40f85dee in QObject::activate_filters(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x40f85d11 in QObject::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#12 0x40fbbf8c in QWidget::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#13 0x41062ae2 in QMainWindow::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#14 0x40f29f24 in QApplication::internalNotify(QObject*, QEvent*) ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#15 0x40f29b19 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#16 0x40b871e9 in KApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libkdecore.so.4
#17 0x40f2acba in QApplication::sendPostedEvents(QObject*, int) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#18 0x40f2ab38 in QApplication::sendPostedEvents() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#19 0x40ee257e in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#20 0x40f3dcf6 in QEventLoop::enterLoop() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#21 0x40f3db98 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#22 0x40f2a151 in QApplication::exec() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#23 0x080640ad in main (argc=7, argv=0xbffff0a4) at main.cpp:95
#24 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

Do you have the history plugin enabled? If so, disable it and let us know if the problem still occurs.  While it may not be a dupe of the other bug related to history, this will help us determine the cause of the problem since the history plugin seems to be the only thing that causes intensive disk activity that I know of.

I have it disabled now, but the problem still occurs.

Then go on disabling plugins.
Btw, I'm almost sure this is a broken X11 driver causing the problem, I never ever experienced this and I do have Kopete running a lot.

Subject: Re: [Kopete-devel]  KDE frequently hangs due to high disk activity when opening chat session

On Sunday 26 October 2003 10:14, Stefan Gehn wrote:
> Then go on disabling plugins.
> Btw, I'm almost sure this is a broken X11 driver causing the problem, I
> never ever experienced this and I do have Kopete running a lot.

Or just the system hitting swap due to high memory usage?

> Or just the system hitting swap due to high memory usage? 
Unlikely because our chatwindow does not need so much ram that your system starts swapping for minutes.
Btw, just a stupid idea: please try upgrading libxslt if possible, maybe flaky versions of that can eat memory too (!it's just an idea and doesn't have to be true!)
 

I've had 0.7.3 running for the past few days without the history plugin enabled, and so far it's worked great.  I'm using KDE 3.1.4 and qt 3.2.1-35.  Also, libxslt-1.0.31-7 and XFree86-4.3.0-111 are installed here.

(All are SuSE builds for SuSE 8.2.)

I'll enable the history plugin again and see what happens... if it does the swap/crash thing, I'll let you know.

*** Bug 67855 has been marked as a duplicate of this bug. ***

Having this problem as well, I have managed to do a VT switch and run top during one of these incidents, X was using about 40% of my CPU and taking up approximately 1.5GB of memory (512MB of physical RAM, the rest swap).

This would suggest to me that it's something in the rendering of the window.

For the case of possible dodgy X drivers, I'm running the latest nVidia drivers.

The annoying thing is that it could be another app too if it's X, notably KWin. Also, under what conditions does a bug in Kopete cause X to allocate more memory, i.e. when does X allocate memory at all for a client app?

Martijn

Subject: Re:  KDE frequently hangs due to high disk activity when opening chat session

On Sunday 14 Dec 2003 7:01 pm, you wrote:
Well afterwards i had swtiched from mdk 9.1 to suse 9.0 . The amazing thing is that the problem has not occured since. Also i had done a recent upgrade to the dri cvs xfree86 (My graphics card is 
S3 prosavage DDR). Well both before and after that i havent been able to recreate the issue. Moreover kbear 3.1 alpha had the same problem also when initiating a new ftp transfer. my guess is that the issue 
is to due to some change they have made to kde. But i repeat that from my experience, i feel this is not a kopete bug. Those who experience this problem could try both kbear and gideon to see whether they 
have had the same issues as me. 

Sarath Menon 

I compiled qt-copy (qt-3.3.0-beta1), kdelibs, kdebase and kdenetwork from CVS HEAD last night and now I am experiencing this memory leak when opening a chat window (just empty chat window, no need to type or receive anything). At first I had the history plugin enabled, but it is still happening after disabling this plugin. I noticed the problem when I left my laptop idle for few hours and when I came back, the system was swapping heavily, all memory was in use. I managed to switch to VT1, at which point the OOM killer killed kopete process and memory was freed.

If I close the chatwindow, kopete doesn't continue to eat memory, until I open chatwindow again. I have tested with ICQ and IRC protocols and both have the problem, so it doesn't seem protocol related. I will also try disabling some other plugins.

Sami: I added you to the CC, so you can follow the discussion and hopefully help us out to fix this.

Do you have any other plugins active? I'm a bit curious what on earth an empty  chat window is doing and why it's leaking.

Martijn

No other plugins. I tested with empty config, adding only one IRC account and opening the server window. Same result.

I can reproduce Sami's leaking here using the new X Resources monitor X-ResTop (http://www.freedesktop.org/Software/xrestop).

On my system I'm leaking about 30kb/sec of X server memory, all of which is attributed to pixmap memory. Closing the window releases the resources, so strictly speaking it's not a leak, but it needs investigation nevertheless.

After about 10 seconds we also start to leak 'normal' memory, about 3 kb/sec, but this memory doesn't seem to be released when we close the window.

I have no iddea what code causes this though, I would need to look at the chat window's code and everything associated to find out.

Martijn

Kopete starts to leak memory here also if I receive a message, but don't open chatwindow (bubble shows on kopete icon on systray telling that new message arrived).

I think that I will next compile with QT 3.2 branch of qt-copy to see if QT 3.3 beta version has anything to do with my leak.

Sami

Subject: Re: [Kopete-devel]  KDE frequently hangs due to high disk activity when opening chat session

On Monday 29 December 2003 15:17, Sami Nieminen wrote:
> I think that I will next compile with QT 3.2 branch of qt-copy to see if QT
> 3.3 beta version has anything to do with my leak.

Unlikely. I'm still using Qt 3.2 and like I said I can reproduce it as well.

After looking at the code I'm puzzled though. There should be little or no 
activity going on with an empty window (I'm not even connected during my 
test!) so where on earth is the pixmap leak coming from?

Subject: Re: [Kopete-devel]  KDE frequently hangs due to high disk activity when opening chat session

On Monday 29 December 2003 15:24, Martijn Klingens wrote:
> After looking at the code I'm puzzled though. There should be little or no
> activity going on with an empty window (I'm not even connected during my
> test!) so where on earth is the pixmap leak coming from?

It's the QMovie used while a send is in progress. Even when the movie is not 
being displayed and just loaded in memory it's leaking pixmaps.

I'm looking at the Qt sources to find the cause of this, but I have too little 
disk space to attempt a Qt recompile at the moment :(

As a workaround just comment out the movie loading around line 462 of 
kopetechatwindow.cpp, but that's not a fix. I can think of another workaround 
that's slightly better, but I first want to know how to fix Qt instead.

I used the workaround and I can confirm that it is not leaking anymore (can use kopete again:).

I wonder what is triggering the leak on my system, since I guess most other systems don't see this. I have a pre-release version of XFree (4.3.99.902), glibc 2.3.3_pre20031222 (with nptl) and gcc 3.3.2.

Sami,

It must be a bug in Qt itself, in QMovie. I have a totally different setup (no prereleases but the versions of XF86 and gcc/glibc as shipped with SuSE 8.2, and Qt 3.2 still) but the same problem.

Martijn

Actually I still experience a memory leak, which seems to be triggered if I don't have chat window open and I receive a message and I have "Flash the system tray on new messages" enabled. Disabling the flash feature makes the memory leak go away.

Sami

Subject: Re: [Kopete-devel]  KDE frequently hangs due to high disk activity when opening chat session

On Thursday 01 January 2004 18:11, Sami Nieminen wrote:
> Actually I still experience a memory leak, which seems to be
> triggered if I don't have chat window open and I receive a message and I
> have "Flash the system tray on new messages" enabled. Disabling the flash
> feature makes the memory leak go away.

Could you please file a separate bug report for that? Multiple independent 
issues in a single bug report are a pain for us to manage and keep track 
of :)

Thanks!

OK, I created a new bug report of the "Flash system tray leak":
http://bugs.kde.org/show_bug.cgi?id=71611

Subject: kdenetwork/kopete/kopete

CVS commit by mklingens: 

Workaround for the pixmap leakage in QMovie: pause the movie while not
being shown. This avoids the initial leaking, although eventually there
might still be a leak up to the size of Qt's pixmap cache. The leak is not
infinite, but this should improve performance a bit and makes sure that
attempts to measure Kopete's resource usage aren't massively skewed. Also
note that closing the chat window frees the pixmaps, so the memory isn't
permanently lost either in a Kopete session.

If there are any other leaks that are properly reproducable (data from
valgrind running in leak-check mode is also welcome, as long as it's a
leak check on a running Kopete and not on exit, and with proper details
on when the check was run) please report in a separate bug report.

CCMAIL: 62669-fixed@bugs.kde.org
CCMAIL: 71611-fixed@bugs.kde.org


  M +19 -35    systemtray.cpp   1.34
  M +3 -0      chatwindow/kopeteemailwindow.cpp   1.30


--- kdenetwork/kopete/kopete/systemtray.cpp  #1.33:1.34
@@ -139,8 +139,9 @@ void KopeteSystemTray::startBlink( const
 }
 
-void KopeteSystemTray::startBlink( const QMovie &icon )
+void KopeteSystemTray::startBlink( const QMovie &movie )
 {
         kdDebug( 14010 ) << k_funcinfo << "starting movie." << endl;
-        setMovie( icon );
+        const_cast<QMovie &>( movie ).unpause();
+        setMovie( movie );
         mIsBlinking = true;
 }
@@ -148,5 +149,6 @@ void KopeteSystemTray::startBlink( const
 void KopeteSystemTray::startBlink()
 {
-        if( mMovie.isNull() )
+        if ( mMovie.isNull() )
+        {
 #if KDE_IS_VERSION(3, 1, 90)
                 mMovie = KGlobal::iconLoader()->loadMovie( QString::fromLatin1( "newmessage" ), KIcon::Panel );
@@ -154,4 +156,6 @@ void KopeteSystemTray::startBlink()
                 mMovie = KopeteCompat::loadMovie( QString::fromLatin1( "newmessage" ), KIcon::Panel );
 #endif
+        }
+
         startBlink( mMovie );
 }
@@ -159,41 +163,22 @@ void KopeteSystemTray::startBlink()
 void KopeteSystemTray::stopBlink()
 {
-        if(movie())
-        {
-                kdDebug(14010) << k_funcinfo << "stopping movie." << endl;
-                setPixmap(mKopeteIcon);
-                mIsBlinkIcon = false;
-                mIsBlinking=false;
-                return;
-        }
-
-        if (mBlinkTimer->isActive() == true)
-        {
+        if ( movie() )
+                kdDebug( 14010 ) << k_funcinfo << "stopping movie." << endl;
+        else if ( mBlinkTimer->isActive() )
                 mBlinkTimer->stop();
-                setPixmap(mKopeteIcon);
-                mIsBlinkIcon = false;
-                mIsBlinking = false;
 
-        }
-        else
-        {
-                setPixmap(mKopeteIcon);
+        if ( !mMovie.isNull() )
+                mMovie.pause();
+
                 mIsBlinkIcon = false;
                 mIsBlinking = false;
-        }
+        setPixmap( mKopeteIcon );
 }
 
 void KopeteSystemTray::slotBlink()
 {
-        if (mIsBlinkIcon == true)
-        {
-                setPixmap(mKopeteIcon);
-                mIsBlinkIcon = false;
-        }
-        else
-        {
-                setPixmap(mBlinkIcon);
-                mIsBlinkIcon = true;
-        }
+        setPixmap( mIsBlinkIcon ? mKopeteIcon : mBlinkIcon );
+
+        mIsBlinkIcon = !mIsBlinkIcon;
 }
 

--- kdenetwork/kopete/kopete/chatwindow/kopeteemailwindow.cpp  #1.29:1.30
@@ -282,4 +282,5 @@ void KopeteEmailWindow::initActions(void
         d->animIcon = KopeteCompat::loadMovie( QString::fromLatin1( "newmessage" ), KIcon::Toolbar);
 #endif
+        d->animIcon.pause();
 
         d->anim = new QLabel( this, "kde toolbar widget" );
@@ -519,4 +520,5 @@ void KopeteEmailWindow::sendMessage()
         d->sendInProgress = true;
         d->anim->setMovie( d->animIcon );
+        d->animIcon.unpause();
         d->btnReplySend->setEnabled( false );
         d->txtEntry->setEnabled( false );
@@ -529,4 +531,5 @@ void KopeteEmailWindow::messageSentSucce
         d->sendInProgress = false;
         d->anim->setPixmap( d->normalIcon );
+        d->animIcon.pause();
         closeView();
 }