Version: (using KDE KDE 3.1) Installed from: RedHat RPMs Compiler: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux OS: Linux From time to time, but at least several times a day, when opening a chat session the session opens, immediatly stalls and kopete (or X?) starts to write/read from disk very intensively. As a result KDE almost dies. The disk activity never stops, at least not for the amount of time i was prepered to wait for it (minutes). I have to kill kopete to stop this. Because i have a standalone machine often i have to do this by a hard reset, but a shell via ctrl-alt- f1 is reachable when there is sufficient patience in me. Currently i'm not sure if it happens both on icq and msn, but surely it happens on icq. This problem exists fo a few weeks, but today, 08-14-2003 i compiled a new cvs version and it happend again with that. (Kopete 0.7.90cvs >= 20030812 (Using KDE 3.1-11 Red Had)
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(); }