Version: 0.7.7 (using KDE 3.2.1, compiled sources) Compiler: gcc version 3.3.3 OS: Linux (i686) release 2.6.3 When i try to quit knode the window closes, but the knode process keeps running. When trying to start knode again, it fails. The same happens to kontact when using knode in kontact. I have this problem since i upgraded to kernel 2.6.x - can it be that knode has a problem with a nptl glibc? I rebuilt whole kde a lot of times from 3.2 branch cvs sources, with different versions of qt (3.2.3, 3.3.0, 3.3.1) - no difference. after quitting, there still is a knode process: > ps aux | grep knode worf 1049 0.2 4.1 50360 21656 ? S 13:33 0:00 knode -caption KNode -icon knode -miniicon knode when trying to start knode again, this happens: > ps aux | grep knode worf 1049 0.2 4.1 50360 21656 ? S 13:33 0:00 knode -caption KNode -icon knode -miniicon knode worf 32628 4.0 2.9 28936 15228 ? S 13:38 0:00 knode -caption KNode -icon knode -miniicon knode worf 32629 0.0 0.0 0 0 ? Z 13:38 0:00 [knode] <defunct>

this is the debug output when quitting: knode: KNMainWidget::requestShutdown() knode: KNMainWidget::prepareShutdown() knode: KNArticleWidget::showBlankPage() libkdenetwork: KScoringManager::save() starts libkdenetwork: KScoringManager::save() creating xml libkdenetwork: KScoringManager::createXMLfromInternal(): libkdenetwork: <?xml version = '1.0'?><!DOCTYPE Scorefile ><Scorefile> </Scorefile> libkdenetwork: libkdenetwork: KScoringManager::save() finished

i just built HEAD, and i get exactely the same problem.

I get the same problem on linux-2.6.5-rc2, glibc-2.3.3 + nptl

I also have the same problem, both as an external app and from within Kontact. linux: 2.6.4 glibc: 2.3.3 (also w/NPTL) qt-x11: 3.3.1 kdelibs: 3.2.1 kdebase: 3.2.1 kdepim: 3.2.1

I also have the same problem, exactly the same versions as Jason Flatt linux: 2.6.4 glibc: 2.3.3 (NPTL) qt-x11: 3.3.1 kdelibs: 3.2.1 kdebase: 3.2.1 kdepim: 3.2.1

I found users which use the versions except that they use linux 2.4 and a glibc without NPTL ( this can only be enabled when using 2.6 kernels ), and this users do NOT have that bug. For me this means that it's almost certain that it's the glibc.

I wish it was related to NPTL... at least I'd have somewhere to start looking. The problem here is that I use a nptl-enabled glibc and I just cannot reproduce the problem. Could you guys try running strace -o /tmp/knode.trace -p <knode's PID> for about a minute or two and then send /tmp/knode.trace to maragato@kde.org? I might hopefully find out what's going on... Also, if you guys could compile knode and run it inside gdb, you might interrupt it when it doesn't die and send me the backtrace.

Not much new about this, i couldn't produce a useful backtrace. However, since my first report i did a lot of compiling and installing, and i can tell you sure that glibc is triggering the bug. All my systems with some NPTL enabled glibc 2.3.3 prerelease show the bug, all others with the standard glibc 2.3.2 without NPTL don't.

It's been a while, so i decided to try it again. in the meantime i'm on kernel 2.6.6, qt 3.3.2, gcc 3.4.1, ... rebuilt glibc with nptl support, and rebuilt the whole system. using kde 3.2 branch from 2004-07-16. Still have the problem. Still have no clue.

*** This bug has been confirmed by popular vote. ***

I have the same problem, often knode is not closing correctly, window is closing, but the process is staying in the process list. A new knode cannot be startes before "killall knode". This seems be related to Suse 9.2, on Suse 9.1 with the same version I've never seen this bug. Knode 0.8.2 (KDE 3.3.2 Level "a" , SUSE 9.2 UNSUPPORTED) Linux (i686) release 2.6.8-24.10-default gcc version 3.3.4 (pre 3.3.5 20040809)

This bug still exists in KDE 3.4 beta 1 and causes kontact to lose all column-settings, e.g. the width of the header-columsn in kmail, as it cannot be shut down properly when quitting the session. This is most annoying. Unexperienced users, who use knode not within kontact will not be able to re-start knode, as the process is not shut down and one would have to kill it.

CVS commit by vkrause: Cleanly terminate network threads from within instead of using QThread::teminate(), which doesn't seem to work on some systems (and which shouldn't be used anyway according to the Qt docs). This fixes the most hated KNode bug (#77381). Thanks to Wolfgang Scheicher <worf@sbox.tu-graz.ac.at> for helping to track this down. CCBUG: 77381 M +1 -1 knnetaccess.cpp 1.39 M +27 -8 knprotocolclient.cpp 1.48 M +3 -1 knprotocolclient.h 1.15 --- kdepim/knode/knnetaccess.cpp #1.38:1.39 @@ -80,5 +80,5 @@ KNNetAccess::~KNNetAccess() mSMTPProgressItem->setComplete(); - nntpClient->terminate(); + nntpClient->terminateClient(); nntpClient->wait(); --- kdepim/knode/knprotocolclient.cpp #1.47:1.48 @@ -35,6 +35,11 @@ -KNProtocolClient::KNProtocolClient(int NfdPipeIn, int NfdPipeOut) -: job(0L), inputSize(10000), fdPipeIn(NfdPipeIn), fdPipeOut(NfdPipeOut), tcpSocket(-1) +KNProtocolClient::KNProtocolClient(int NfdPipeIn, int NfdPipeOut) : + job( 0 ), + inputSize( 10000 ), + fdPipeIn( NfdPipeIn ), + fdPipeOut( NfdPipeOut ), + tcpSocket( -1 ), + mTerminate( false ) { input = new char[inputSize]; @@ -90,4 +95,5 @@ void KNProtocolClient::waitForWork() while (true) { + int holdTime = 2 * account.hold(); if (isConnected()) { // we are connected, hold the connection for xx secs FD_ZERO(&fdsR); @@ -96,8 +102,10 @@ void KNProtocolClient::waitForWork() FD_ZERO(&fdsE); FD_SET(tcpSocket, &fdsE); - tv.tv_sec = account.hold(); - tv.tv_usec = 0; + tv.tv_sec = 0; + tv.tv_usec = 500; + --holdTime; selectRet = KSocks::self()->select(FD_SETSIZE, &fdsR, NULL, &fdsE, &tv); if (selectRet == 0) { + if (holdTime <= 0) { #ifndef NDEBUG qDebug("knode: KNProtocolClient::waitForWork(): hold time elapsed, closing connection."); @@ -105,4 +113,10 @@ void KNProtocolClient::waitForWork() closeConnection(); // nothing happend... } else { + if ( mTerminate ) { + closeConnection(); + return; + } + } + } else { if (((selectRet > 0)&&(!FD_ISSET(fdPipeIn,&fdsR)))||(selectRet == -1)) { #ifndef NDEBUG @@ -114,8 +128,13 @@ void KNProtocolClient::waitForWork() } + struct timeval timeout; do { + timeout.tv_sec = 0; + timeout.tv_usec = 500; FD_ZERO(&fdsR); FD_SET(fdPipeIn, &fdsR); - } while (select(FD_SETSIZE, &fdsR, NULL, NULL, NULL)<0); // don't get tricked by signals + if (mTerminate) + return; + } while (select(FD_SETSIZE, &fdsR, NULL, NULL, &timeout) <= 0); // don't get tricked by signals clearPipe(); // remove start signal --- kdepim/knode/knprotocolclient.h #1.14:1.15 @@ -52,4 +52,5 @@ class KNProtocolClient : public QThread bool isInByteCountMode() const { return byteCountMode; }; + void terminateClient() { mTerminate = true; } protected: @@ -115,4 +116,5 @@ class KNProtocolClient : public QThread int byteCount; QTime timer; + bool mTerminate; };

Backport to 3.4 branch follows as soon as 3.4.0 is released, ie. this fix will not be in 3.4.0 but 3.4.1.

... Rejoice, Rejoice ..! :-) This is the moment to migrate a handful of PCs to new glibc...

Thanks, Volker, for finding and fixing this bug! /me patiently awaits 3.4.1, while discovering all the new things in 3.4.0-rc1 :^)

CVS commit by vkrause: Backport fix for #77381 (Cleanly terminate network threads). BUG: 77381 M +2 -2 knnetaccess.cpp 1.37.2.1 M +29 -8 knprotocolclient.cpp 1.47.2.1 M +3 -1 knprotocolclient.h 1.14.14.1 --- kdepim/knode/knnetaccess.cpp #1.37:1.37.2.1 @@ -90,7 +90,7 @@ KNNetAccess::~KNNetAccess() mSMTPProgressItem->setComplete(); - nntpClient->terminate(); + nntpClient->terminateClient(); nntpClient->wait(); - smtpClient->terminate(); + smtpClient->terminateClient(); smtpClient->wait(); --- kdepim/knode/knprotocolclient.cpp #1.47:1.47.2.1 @@ -35,6 +35,11 @@ -KNProtocolClient::KNProtocolClient(int NfdPipeIn, int NfdPipeOut) -: job(0L), inputSize(10000), fdPipeIn(NfdPipeIn), fdPipeOut(NfdPipeOut), tcpSocket(-1) +KNProtocolClient::KNProtocolClient(int NfdPipeIn, int NfdPipeOut) : + job( 0 ), + inputSize( 10000 ), + fdPipeIn( NfdPipeIn ), + fdPipeOut( NfdPipeOut ), + tcpSocket( -1 ), + mTerminate( false ) { input = new char[inputSize]; @@ -89,4 +94,5 @@ void KNProtocolClient::waitForWork() int selectRet; + int holdTime = 1000 * account.hold(); while (true) { if (isConnected()) { // we are connected, hold the connection for xx secs @@ -96,12 +102,22 @@ void KNProtocolClient::waitForWork() FD_ZERO(&fdsE); FD_SET(tcpSocket, &fdsE); - tv.tv_sec = account.hold(); - tv.tv_usec = 0; + tv.tv_sec = 0; + tv.tv_usec = 1000; + --holdTime; selectRet = KSocks::self()->select(FD_SETSIZE, &fdsR, NULL, &fdsE, &tv); if (selectRet == 0) { + if (holdTime <= 0) { #ifndef NDEBUG qDebug("knode: KNProtocolClient::waitForWork(): hold time elapsed, closing connection."); #endif closeConnection(); // nothing happend... + holdTime = 1000 * account.hold(); + } else { + if ( mTerminate ) { + closeConnection(); + return; + } + continue; + } } else { if (((selectRet > 0)&&(!FD_ISSET(fdPipeIn,&fdsR)))||(selectRet == -1)) { @@ -114,8 +130,13 @@ void KNProtocolClient::waitForWork() } + struct timeval timeout; do { + timeout.tv_sec = 0; + timeout.tv_usec = 1000; FD_ZERO(&fdsR); FD_SET(fdPipeIn, &fdsR); - } while (select(FD_SETSIZE, &fdsR, NULL, NULL, NULL)<0); // don't get tricked by signals + if (mTerminate) + return; + } while (select(FD_SETSIZE, &fdsR, NULL, NULL, &timeout) <= 0); // don't get tricked by signals clearPipe(); // remove start signal --- kdepim/knode/knprotocolclient.h #1.14:1.14.14.1 @@ -52,4 +52,5 @@ class KNProtocolClient : public QThread bool isInByteCountMode() const { return byteCountMode; }; + void terminateClient() { mTerminate = true; } protected: @@ -115,4 +116,5 @@ class KNProtocolClient : public QThread int byteCount; QTime timer; + bool mTerminate; };

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

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

Hi to all, this is my first bug search and I don't know very well what I have to do. I have the same problem with knode on a machine running FC-4/KDE-3.4.1. How can I resolve my problem? Have I to rebuild knode? I upgraded it by yum. Thanks in advance, Salvatore La Bua.

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