Version: 0.7.1 (using KDE 3.1.3) Installed from: compiled sources Compiler: gcc version 3.2.2 OS: Linux (i686) release 2.4.20 I'm not quite sure how to file this report...because I have no idea what causes it. I currently have one account each for Yahoo, AIM, Jabber, ICQ, and MSN. I got up this morning to find Kopete in what appeared to be a usable state, though the people I expected to be online based on the time of day weren't, and vice versa. So I hit Set Available Globally, and noticed that only the AIM and Jabber icons changed to available, so I tried changing the others manually. When this had no effect, I tried setting them to offline. This also had no effect. I then discovered that clicking on peoples aliases to chat with them didn't work. I restarted Kopete and all was well. This is the second time this has happened, and I've been running into a lot of occurances where the online status is not reported accurately for at least AIM, so I wonder if these are related. In every case, Kopete gets weird and unusable (no hard crash), and a quick restart fixes everything, which would indicate that it's not a problem with my configuration. If somebody can tell me how to run Kopete in debug mode or how to investigate this further, I'd be happy to provide more information.
Subject: Re: [Kopete-devel] New: Kopete hangs unpredictably after running for too long On Thursday 04 September 2003 20:09, Casey Allen Shobe wrote: > If somebody can tell me how to run Kopete in debug mode or how to > investigate this further, I'd be happy to provide more information. Configure with --enable-debug=full, rebuild and reinstall. After that, install valgrind and run 'valgrind --num-callers=12 --logfile=vg.log kopete --nofork' gzip the logfile when done and mail it here. Instead of using --logfile you can also redirect stdout and stderr so there's also the Kopete debug output: 'valgrind --num-callers=12 kopete --nofork &> vg.log'
You might also find that the problem doesn't manifest under valgrind, but that running Kopete from the console and redirecting its output into a file and seeing what's happened towards the end.
More research indicates that this is definitely an Oscar problem, which I didn't realize at first because I have very few contacts on other protocols. It doesn't hang until I've left it idle for a long time (i.e. sleep), so perhaps I will try firing it up with valgrind (sloooooows down my box) next time I head off to sleep. Anyways...here's what I have been able to come up with. When I find kopete in this state, both ICQ and AIM contacts are shown in their previous state, and both types of connection are shown as online. However, while I *AM* able to disconnect/reconnect jabber/msn/yahoo, hitting disconnect on AIM or ICQ does nothing. Here's a bit if console output: # Okay, Kopete is fud up. Let's try signing off all the accounts... # Here goes MSN... kopete: MSNSocket::slotSocketClosed: socket closed. State: 0x40 kopete: MSNAccount::slotNotifySocketClosed kopete: MSNNotifySocket::~MSNNotifySocket # Trying AIM...gives this first line of output but that's it. The status never really changes. I'm not sure about the sigpipe - see farther down. kopete: [virtual void OscarSocket::doLogoff()] Sending sign off request *** SIGPIPE *** (ignored, pid = 945) # Here goes jabber. kopete: [void JabberAccount::slotGoOffline()] called. kopete: [JabberAccount] disconnect() called kopete: [JabberAccount] Still connected, closing connection... kopete: [JabberAccount] Disconnected. kopete: [JabberAccount] Disconnected from Jabber server. # Attempting ICQ. Again, there is no indication in the GUI to show any change of status. kopete: [virtual void OscarSocket::doLogoff()] Sending sign off request # Here goes Yahoo... kopete: Attempting to disconnect from Yahoo server kopete: [void YahooSession::logOff()] 1 kopete: [void YahooSessionManager::removeHandlerReceiver(int, int)] kopete: [void YahooSessionManager::removeHandlerReceiver(int, int)] Session: 1 Socket: 14 kopete: [void YahooSessionManager::removeHandlerReceiver(int, int)] read off kopete: [void YahooSessionManager::removeHandlerReceiver(int, int)] write off kopete: Yahoo::setYahooStatus( 0, ) kopete: Yahoo::setYahooStatus( 0, ) kopete: Yahoo::setYahooStatus( 0, ) # As I typed this with Kopete supposedly not online with anything except maybe AIM and ICQ: *** SIGPIPE *** (ignored, pid = 945) kopete: ConnectionStatusPlugin::checkStatus() kopete: ConnectionStatusPlugin::slotProcessStdout() kopete: ConnectionStatusPlugin::setConnectedStatus() *** SIGPIPE *** (ignored, pid = 945) kopete: ConnectionStatusPlugin::checkStatus() kopete: ConnectionStatusPlugin::slotProcessStdout() kopete: ConnectionStatusPlugin::setConnectedStatus() *** SIGPIPE *** (ignored, pid = 945) kopete: ConnectionStatusPlugin::checkStatus() kopete: ConnectionStatusPlugin::slotProcessStdout() kopete: ConnectionStatusPlugin::setConnectedStatus() *** SIGPIPE *** (ignored, pid = 945) kopete: ConnectionStatusPlugin::checkStatus() kopete: ConnectionStatusPlugin::slotProcessStdout() kopete: ConnectionStatusPlugin::setConnectedStatus() *** SIGPIPE *** (ignored, pid = 945) kopete: ConnectionStatusPlugin::checkStatus() kopete: ConnectionStatusPlugin::slotProcessStdout() kopete: ConnectionStatusPlugin::setConnectedStatus() Looking at a 'ps aux -H' output, process 945 is the master kopete process: rivyn 945 0.0 2.6 43396 24144 pts/2 S 02:20 0:30 kopete rivyn 947 0.0 2.6 43396 24144 pts/2 S 02:20 0:00 kopete When I then try to shutdown Kopete normally using the quit option in the GUI, it terminates with a signal 11 (it does this every time it locks up) Here's some probably useless console output from when I try to shut down: kopete: [virtual void YahooContact::serialize(QMap<QString, QString>&, QMap<QString, QString>&)] kopete: [void KopeteAccountManager::save()] kparts: KPart::slotWidgetDestroyed(), deleting part unnamed khtml: KHTMLFactory::~KHTMLFactory kparts: Part::~Part 0x82678f0 kopete: [virtual YahooPreferences::~YahooPreferences()] kopete: ConnectionStatusPlugin::~ConnectionStatusPlugin() kopete: [virtual YahooProtocol::~YahooProtocol()] kopete: [void KopeteAccountManager::unregisterAccount(KopeteAccount*)] Unregistering account SomeLinuxGuy kopete: [virtual AIMAccount::~AIMAccount()] [SomeLinuxGuy] deleted kopete: [virtual OscarAccount::~OscarAccount()] 'SomeLinuxGuy' deleted, Disconnecting... kopete: [virtual void OscarAccount::disconnect()] accountID='SomeLinuxGuy' kopete: [virtual void OscarSocket::doLogoff()] Sending sign off request kopete: [void OscarSocket::slotConnectionClosed()] Connection for account 'SomeLinuxGuy' closed. kopete: [void OscarSocket::slotConnectionClosed()] Socket state is 0 kopete: [void OscarSocket::slotConnectionClosed()] emitting statusChanged(OSCAR_OFFLINE) kopete: [void OscarAccount::slotOurStatusChanged(unsigned int)] Called; newStatus=0 kopete: [virtual OscarAccount::~OscarAccount()] 'SomeLinuxGuy' deleting myself() contact kopete: [void KopeteAccountManager::unregisterAccount(KopeteAccount*)] Unregistering account SomeLinuxGuy kopete: [JabberAccount] disconnect() called kopete: [JabberAccount] Disconnected. kopete: [void KopeteAccountManager::unregisterAccount(KopeteAccount*)] Unregistering account sigthor@jabber.org kopete: [virtual ICQAccount::~ICQAccount()] [1494523] deleted kopete: [virtual OscarAccount::~OscarAccount()] '1494523' deleted, Disconnecting... kopete: [virtual void OscarAccount::disconnect()] accountID='1494523' kopete: [virtual void OscarSocket::doLogoff()] Sending sign off request *** SIGPIPE *** (ignored, pid = 945) kopete: [void OscarSocket::slotConnectionClosed()] Connection for account '1494523' closed. kopete: [void OscarSocket::stopKeepalive()] Deleting keepaliveTimer kopete: [void OscarSocket::slotConnectionClosed()] Socket state is 0 kopete: [void OscarSocket::slotConnectionClosed()] emitting statusChanged(OSCAR_OFFLINE) kopete: [void OscarAccount::slotOurStatusChanged(unsigned int)] Called; newStatus=0 kopete: [virtual OscarAccount::~OscarAccount()] '1494523' deleting myself() contact ...and here's a backtrace: [New Thread 16384 (LWP 945)] [New Thread 32769 (LWP 947)] 0x416b3f29 in wait4 () from /lib/libc.so.6 #0 0x416b3f29 in wait4 () from /lib/libc.so.6 #1 0x41734234 in __DTOR_END__ () from /lib/libc.so.6 #2 0x414c9103 in waitpid () from /lib/libpthread.so.0 #3 0x40c1ff31 in KCrash::defaultCrashHandler(int) () from /opt/kde/lib/libkdecore.so.4 #4 <signal handler called> #5 0x0806fcd8 in QString::~QString() () #6 0x400459f3 in KopeteOnlineStatus::~KopeteOnlineStatus() () from /opt/kde/lib/libkopete.so.1 #7 0x4004ce17 in KopeteContact::~KopeteContact() () from /opt/kde/lib/libkopete.so.1 #8 0x42145ede in OscarContact::~OscarContact() () from /opt/kde/lib/libkopete_oscar.so.1 #9 0x424447d3 in ICQContact::~ICQContact() () from /opt/kde/lib/kde3/kopete_icq.so #10 0x40083203 in KopeteAccount::~KopeteAccount() () from /opt/kde/lib/libkopete.so.1 #11 0x42135326 in OscarAccount::~OscarAccount() () from /opt/kde/lib/libkopete_oscar.so.1 #12 0x4243ba49 in ICQAccount::~ICQAccount() () from /opt/kde/lib/kde3/kopete_icq.so #13 0x40047023 in KopeteProtocol::~KopeteProtocol() () from /opt/kde/lib/libkopete.so.1 #14 0x42428dab in ICQProtocol::~ICQProtocol() () from /opt/kde/lib/kde3/kopete_icq.so #15 0x40051cd4 in LibraryLoader::~LibraryLoader() () from /opt/kde/lib/libkopete.so.1 #16 0x4005747f in KStaticDeleter<LibraryLoader>::destructObject() () from /opt/kde/lib/libkopete.so.1 #17 0x40c2b28d in KGlobal::deleteStaticDeleters() () from /opt/kde/lib/libkdecore.so.4 #18 0x40ba34eb in KApplication::~KApplication() () from /opt/kde/lib/libkdecore.so.4 #19 0x40c3cd13 in KUniqueApplication::~KUniqueApplication() () from /opt/kde/lib/libkdecore.so.4 #20 0x0806f150 in Kopete::~Kopete() () #21 0x0806ed8e in main () #22 0x4161bbb4 in __libc_start_main () from /lib/libc.so.6 Now if this weren't enough, if I start Kopete again, it eats up all my CPU and my computer gets real slow (kinda like running valgrind ;-P), and Kopete proceeds to act very strange and crash without too much delay. With a little investigation, I've discovered that this only happens if I don't go manually kill off kopete processes after it crashes. I.e. right now: rivyn 947 0.1 2.7 43392 24756 pts/2 T 02:20 0:37 kopete This is after I issued a quit command AND it crashed. Apparently the child processes hang around and do god-knows-what to the new processes.
Oh, I forgot to mention that I'm using Kopete 0.7.2 now. The behavior described here is identical under 0.7.1.
Go ditch the fucking stupid connectionstatus plugin, it's NOT safe to use.
Umm, okay. Then why does it get compiled in by default and not have any warning? I would propose that buggy plugins have their descriptions prefixed with 'EXPERIMENTAL: ' Anyways, it's removed now. I'll keep you updated. Thanks.
Created attachment 2436 [details] Create new KProcess for each netstat, instead of reusing it. I just asked Oswald (KProcess maintainer) on IRC and the way ConnectionStatus is reusing the process is not guaranteed to be safe. Could you try this patch? It creates a new process instead of reusing it, might avoid memory corruption and other problems. Also avoids starting the process if the previous one is still running due to high system load. Martijn
user rivyn@eirny:/home/rivyn/downloads/kopete-0.7.2 $ patch -Np1 -i ../kopete-martijn.patch missing header for unified diff at line 8 of patch can't find file to patch at input line 8 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: connectionstatusplugin.cpp |=================================================================== |RCS file: /home/kde/kdenetwork/kopete/plugins/connectionstatus/connectionstatusplugin.cpp,v |retrieving revision 1.18 |diff -u -p -r1.18 connectionstatusplugin.cpp |--- connectionstatusplugin.cpp 28 Aug 2003 19:22:31 -0000 1.18 |+++ connectionstatusplugin.cpp 12 Sep 2003 20:59:44 -0000 -------------------------- File to patch: kopete/plugins/connectionstatus/connectionstatusplugin.cpp patching file kopete/plugins/connectionstatus/connectionstatusplugin.cpp Hunk #1 succeeded at 33 (offset -2 lines). missing header for unified diff at line 69 of patch can't find file to patch at input line 69 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: connectionstatusplugin.h |=================================================================== |RCS file: /home/kde/kdenetwork/kopete/plugins/connectionstatus/connectionstatusplugin.h,v |retrieving revision 1.5 |diff -u -p -r1.5 connectionstatusplugin.h |--- connectionstatusplugin.h 13 Feb 2003 16:45:30 -0000 1.5 |+++ connectionstatusplugin.h 12 Sep 2003 20:59:44 -0000 -------------------------- File to patch: kopete/plugins/connectionstatus/connectionstatusplugin.h patching file kopete/plugins/connectionstatus/connectionstatusplugin.h Seems it only half-applied. Is this intended to be used against CVS?
Subject: Re: [Kopete-devel] Kopete hangs unpredictably after running for too long On Saturday 13 September 2003 19:59, Sig
Didn't apply entirely to CVS either: user rivyn@eirny:/home/rivyn/kdenetwork $ patch -Np1 -i ../downloads/kopete-martijn.patch missing header for unified diff at line 8 of patch can't find file to patch at input line 8 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: connectionstatusplugin.cpp |=================================================================== |RCS file: /home/kde/kdenetwork/kopete/plugins/connectionstatus/connectionstatusplugin.cpp,v |retrieving revision 1.18 |diff -u -p -r1.18 connectionstatusplugin.cpp |--- connectionstatusplugin.cpp 28 Aug 2003 19:22:31 -0000 1.18 |+++ connectionstatusplugin.cpp 12 Sep 2003 20:59:44 -0000 -------------------------- File to patch: kopete/plugins/connectionstatus/connectionstatusplugin.cpp patching file kopete/plugins/connectionstatus/connectionstatusplugin.cpp missing header for unified diff at line 69 of patch can't find file to patch at input line 69 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: connectionstatusplugin.h |=================================================================== |RCS file: /home/kde/kdenetwork/kopete/plugins/connectionstatus/connectionstatusplugin.h,v |retrieving revision 1.5 |diff -u -p -r1.5 connectionstatusplugin.h |--- connectionstatusplugin.h 13 Feb 2003 16:45:30 -0000 1.5 |+++ connectionstatusplugin.h 12 Sep 2003 20:59:44 -0000 -------------------------- File to patch: kopete/plugins/connectionstatus/connectionstatusplugin.h patching file kopete/plugins/connectionstatus/connectionstatusplugin.h
Got it applied and build...running it now. Not sure why it thinks my system is under high load... user rivyn@eirny:/home/rivyn $ uptime 15:27:22 up 11:12, 1 user, load average: 0.42, 0.36, 0.49 kio (KTrader): KServiceTypeProfile::offers( Kopete/Plugin, ) kio (KTrader): Returning 20 offers kopete: ConnectionStatusPlugin::ConnectionStatusPlugin() kopete: [KopetePlugin* LibraryLoader::loadPlugin(const QString&)] Successfully loaded plugin 'connectionstatus' kopete: [void KopeteAccountManager::save()] QFile::open: No file name specified kopete: [virtual void YahooPreferences::save()] kopete: YahooProtocol::slotSettingsChanged() kopete: [void KopeteAccountManager::save()] kopete: [virtual void YahooPreferences::save()] kopete: YahooProtocol::slotSettingsChanged() kopete: << PING :irc.linuxfromscratch.org kopete: >> PONG :irc.linuxfromscratch.org kopete: MSNSocket::slotReadyWrite: Sending command PNG kopete: kopete: MSNSocket::slotDataReceived: Received 'QNG 46 kopete: ' kopete: >> ISON daisy xerxes kopete: << :entropy.nl.eu.zirc.org 303 sigthor :daisy xerxes kopete: [void YahooSession::slotReadReady()] 14 kopete: [void YahooSessionManager::statusChangedReceiver(int, char*, int, char*, int)] kopete: [void YahooAccount::slotStatusChanged(const QString&, int, const QString&, int)] cucular, 2, , 1] kopete: Yahoo::setYahooStatus( 4, ) kopete: [void AIMContact::slotContactChanged(const UserInfo&)] AIM user kopete: [void AIMContact::slotContactChanged(const UserInfo&)] AIM user kopete: [void AIMContact::slotContactChanged(const UserInfo&)] AOL trial account kopete: [void ConnectionStatusPlugin::slotCheckStatus()] kopete: WARNING: [void ConnectionStatusPlugin::slotCheckStatus()] Previous netstat process is still running! kopete: Not starting new netstat. Your system seems to be under heavy load. kopete: MSNSocket::slotReadyWrite: Sending command PNG kopete: kopete: MSNSocket::slotDataReceived: Received 'QNG 42 kopete: ' kopete: >> ISON daisy xerxes kopete: << :entropy.nl.eu.zirc.org 303 sigthor :daisy xerxes kopete: << PING :irc.linuxfromscratch.org kopete: >> PONG :irc.linuxfromscratch.org
*** Bug 63377 has been marked as a duplicate of this bug. ***
Subject: Re: [Kopete-devel] Kopete hangs unpredictably after running for too long On Saturday 13 September 2003 21:28, Sig
Well, it's not crashing with the patch applied...but neither is my system under high load. netstat (with and without -n) completes instantly. You *may* want to think about -n, as I've seen netstat hang for a good long while waiting on DNS. Then again, that could be something you were looking for. user rivyn@eirny:/home/rivyn/scsi/kopete/kopete $ netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface localnet * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default launchmodem 0.0.0.0 UG 0 0 0 eth0 user rivyn@eirny:/home/rivyn/scsi/kopete/kopete $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 I'm building KDE from CVS now, so I'll try your patch and suggestions against Kopete-CVS (unless you specifically want me to run 0.7.2, in which case I will).
Subject: Re: [Kopete-devel] Kopete hangs unpredictably after running for too long On Sunday 14 September 2003 16:35, Sig
Martijn: Just got KDE CVS and Kopete CVS compiled (all with --enable-debug=full), applied your patch, made the suggested kdebug additions, set the timeout to 10 seconds...and here's the only console output: kopete (connectionstatus): Not starting new netstat. Your system seems to be under heavy load. kopete (connectionstatus): [void ConnectionStatusPlugin::slotCheckStatus()] kopete (connectionstatus): WARNING: [void ConnectionStatusPlugin::slotCheckStatus()] Previous netstat process is still running! kopete (connectionstatus): Not starting new netstat. Your system seems to be under heavy load. kopete (connectionstatus): [void ConnectionStatusPlugin::slotCheckStatus()] kopete (connectionstatus): WARNING: [void ConnectionStatusPlugin::slotCheckStatus()] Previous netstat process is still running! [last 4 lines repeat infinitely]
Ouch, I think I found the bug... The initialization of kpIfconfig is moved out of the constructor, but now it's never initialized in the ctor. Could you add the following line to the constructor? kpIfconfig = 0L; Somehow I expect a lot more results now... Martijn
Subject: Re: [Kopete-devel] Connection Status plugin causes eventual Kopete hang On Monday 15 September 2003 18:47, Martijn Klingens wrote: > Ouch, I think I found the bug... Rock on. > The initialization of kpIfconfig is moved out of the constructor, but now > it's never initialized in the ctor. Could you add the following line to the > constructor? If you wanna tell me what a constructor is and where I might find it. I had to spend a few minutes deciphering your last request (and then it errored out because the one for slotProcessStdout needed to be at the end, not the beginning so that it was declared first). Keep in mind that I'm just an end user with some PHP background. C++ and KDE code are a whole new world to me. But I'm happy to learn and help in whatever ways I may. I just need a bit of explanation here ;-).
Created attachment 2470 [details] A slightly modified version of the first patch to handle Martijn's request
I just attached a new patch to this bug report. You'll have to revert the old patch to use it (this can be done using cvs update -C) and apply the new patch instead, which is a combination of Martijn's first patch and his last suggestion (setting kpIfconfig = 0L).
Subject: Re: [Kopete-devel] Connection Status plugin causes eventual Kopete hang On Tuesday 16 September 2003 02:46, Sig
Subject: kdenetwork/kopete/plugins/connectionstatus CVS commit by mklingens: - Don't reuse KProcess, it's unreliable and causes Kopete to hang. Fixes CCMAIL: 63717-done@bugs.kde.org - Check for proper process creation, don't spawn new process when the old process is still running - Use Kopete standard license headers - Remove unused member vars, rename the others to use a consistent naming - Clean up the coding style to be consistent again M +89 -61 connectionstatusplugin.cpp 1.20 M +27 -25 connectionstatusplugin.h 1.6