Version: 4.0 (using KDE 3.1.9) Compiler: gcc version 3.2.2 20021231 (Debian prerelease) OS: Linux (i686) release 2.4.19-xfs Hi, I compiled KDE on Debian unstable with gcc-3.2, however, kio_http crashes allmost all the time with the following bt: #0 0x4017e01d in KIO::TCPSlaveBase::connectToHost(QString const&, unsigned, bool) ( this=0xbfffee78, host=@0xbfffeed0, _port=80, sendError=false) at /usr/src/KDE/kde-cvs/kdelibs/kio/kio/tcpslavebase.cpp:346 #1 0x411ffef5 in HTTPProtocol::httpOpenConnection() (this=0xbfffee50) at /usr/src/KDE/kde-cvs/kdelibs/kioslave/http/http.cc:1810 #2 0x41201c27 in HTTPProtocol::httpOpen() (this=0xbfffee50) at /usr/src/KDE/kde-cvs/kdelibs/kioslave/http/http.cc:2321 #3 0x411f3ca2 in HTTPProtocol::retrieveHeader(bool) (this=0xbfffee50, close_connection=false) at /usr/src/KDE/kde-cvs/kdelibs/kioslave/http/http.cc:409 #4 0x411f3981 in HTTPProtocol::retrieveContent(bool) (this=0xbfffee50, dataInternal=false) at /usr/src/KDE/kde-cvs/kdelibs/kioslave/http/http.cc:379 #5 0x411fa3ac in HTTPProtocol::get(KURL const&) (this=0xbfffee50, url=@0xbfffec30) at /usr/src/KDE/kde-cvs/kdelibs/kioslave/http/http.cc:1126 #6 0x4018b017 in KIO::SlaveBase::dispatch(int, QMemArray<char> const&) (this=0xbfffee78, command=67, data=@0xbfffec30) at /usr/src/KDE/kde-cvs/kdelibs/kio/kio/slavebase.cpp:933 #7 0x40186677 in KIO::SlaveBase::dispatchLoop() (this=0xbfffee78) at /usr/src/KDE/kde-cvs/kdelibs/kio/kio/slavebase.cpp:264 #8 0x411eefe0 in kdemain (argc=4, argv=0xbfffee30) at /usr/src/KDE/kde-cvs/kdelibs/kioslave/http/http.cc:91 #9 0x0804cae2 in launch (argc=4, _name=0x805cd3c "kio_http", args=0x805cdae "", cwd=0x0, envc=0, envs=0xbffff540 " \231\005\b\020±\005\b\234c\aAÆÑh@\f", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x804f213 "0") at /usr/src/KDE/kde-cvs/kdelibs/kinit/kinit.cpp:561 I don't know if it's gcc's fault or a bug in the code that doesn't show up with gcc-2. Thanks, Michael
Hello, Come on. Reporting bugs after compiling the code with a development version of a compiler. Say it ain't so :))) Seriously though this must be gcc issue. The bt says the cause of the crash is is line 346 in tcpslavebase.cpp. This is bogus since that is an empty line! FWIW, I am using gcc 3.2.1 on Gentoo and have not encountered this problem. Regards, Dawit A.
Subject: Re: kio_http crashes in 80% of all cases On Sunday 05 January 2003 07:15, you wrote: > Come on. Reporting bugs after compiling the code with a development > version of a compiler. Say it ain't so :))) *grin* :-) Well... what to say? ;) > Seriously though this must be > gcc issue. The bt says the cause of the crash is is line 346 in > tcpslavebase.cpp. This is bogus since that is an empty line! Erm.. for me, it's this: // store the IP for later const KSocketAddress *sa = ks.peerAddress(); d->ip = sa->nodeName(); //// <--- Line 346 ks.release(); // KExtendedSocket no longer applicable if ( d->block != ks.blockingMode() ) ks.setBlockingMode( d->block ); > FWIW, I am using gcc 3.2.1 on Gentoo and have not encountered this problem. Strange, it didn't work with gcc 3.2.1 on Debian as well... damn. Do you have any idea how to use valgrind for kio_http? Maybe this gives a somewhat better report.
Subject: Re: kio_http crashes in 80% of all cases > > Seriously though this must be > > gcc issue. The bt says the cause of the crash is is line 346 in > > tcpslavebase.cpp. This is bogus since that is an empty line! > > Erm.. for me, it's this: > > // store the IP for later > const KSocketAddress *sa = ks.peerAddress(); > d->ip = sa->nodeName(); //// <--- Line 346 Ooops indeed... I had added a couple of debug statements to my copy. However, I still do not get the crashes you mentioned though. Do you get the crash dialog when this happens or did you start debugging it because you could not connect to a lot of sites ? > ks.release(); // KExtendedSocket no longer applicable > > if ( d->block != ks.blockingMode() ) > ks.setBlockingMode( d->block ); > > > FWIW, I am using gcc 3.2.1 on Gentoo and have not encountered this > > problem. > > Strange, it didn't work with gcc 3.2.1 on Debian as well... damn. Do you > have any idea how to use valgrind for kio_http? Maybe this gives a somewhat > better report. Unfotunately I don't. Last I remember you could not, but I could be wrong. Regards, Dawit A.
Subject: Re: kio_http crashes in 80% of all cases On Monday 06 January 2003 01:22, you wrote: > Do you get > the crash dialog when this happens or did you start debugging it because > you could not connect to a lot of sites ? First no, second yes. I exported KDE_SLAVE_DEBUG_WAIT=http or something like that and attached gdb.
Subject: Re: kio_http crashes in 80% of all cases The problem seems to be that ks.peerAddress(); returns 0. It is easy to handle this in tcpslavebase.cpp (will fix it there) but the more interesting question is why it returns 0 in the first place. Could you add some debug statements in front of the various "return NULL;" statements in KExtendedSocket::peerAddress() and KExtendedSocket::peerAddress(int fd) ? (kdelibs/kdecore/kextsock.cpp) Cheers, Waldo
Subject: kdelibs/kio/kio CVS commit by waba: CCMAIL: 52612@bugs.kde.org Don't crash when KExtendedSocket::peerAddress() fails. M +5 -2 tcpslavebase.cpp 1.119 --- kdelibs/kio/kio/tcpslavebase.cpp #1.118:1.119 @@ -344,5 +344,8 @@ bool TCPSlaveBase::connectToHost( const // store the IP for later const KSocketAddress *sa = ks.peerAddress(); + if (sa) d->ip = sa->nodeName(); + else + d->ip = ""; ks.release(); // KExtendedSocket no longer applicable
Subject: Re: kio_http crashes in 80% of all cases > The problem seems to be that ks.peerAddress(); returns 0. It is easy to > handle this in tcpslavebase.cpp (will fix it there) but the more > interesting question is why it returns 0 in the first place. Could you add > some debug statements in front of the various "return NULL;" statements in > KExtendedSocket::peerAddress() and KExtendedSocket::peerAddress(int fd) ? Done, the output is now this: 14:02:58 libtsocks(5917): Call to connect received on completed request 9 kio_http: ***************** Line 2287, peerAddress(int fd) ********** kioslave : ###############SEG FAULT############# So I should note that I'm using socks. Hmm. Testing without... Indeed! The internal MWN pages work without crashing by unsetting LD_PRELOAD. So is this a bug in tsocks? Dunno what its output above means... btw, the code that returns NULL is in peerAddress(int fd): /* find out the socket length, in advance * we use a sockaddr allocated on the heap just not to pass down * a NULL pointer to the first call. Some systems are reported to * set len to 0 if we pass NULL as the sockaddr */ if (KSocks::self()->getpeername(fd, sa, &len) == -1) return NULL; // error Thanks,
Subject: Re: kio_http crashes in 80% of all cases > CCMAIL: 52612@bugs.kde.org > Don't crash when KExtendedSocket::peerAddress() fails. Not sure if this helps in our case---I still get "Connection to blah is broken", in konsole there's no ### SEGFAULT ### line but a kio (kioslave): SIGPIPE
The connection gets dropped from the socks side of things it seems. That causes the SIGPIPE (which is gracefully handled and turned into a "Connection to blah is broken" message)
Can you try to strace the io-slaves to see what socks is doing? Please attach the strace log as an attachment to this bugreport.
Subject: Re: kio_http connection problems with socks On Wednesday 08 January 2003 12:51, you wrote: > Can you try to strace the io-slaves to see what socks is doing? Please > attach the strace log as an attachment to this bugreport. I've got severe problems doing so. konqy creates many, many kio_https, everyone stopping because of KDE_SLAVE_DEBUG_WAIT. strace can only be attached to one of them at the same time. And the SIGPIPE comes only on every 10th or 20th slave :( Although that's once on every third page for me (missing images, for example). Sometimes, even reload doesn't help, but that was two days ago, didn't happen anymore. Do you have any more hints? I'll try them this evening, my time is running out now... Thanks,
Subject: Re: kio_http connection problems with socks On Wednesday 08 January 2003 13:14, Michael Brade wrote: > Do you have any more hints? Don't set KDE_SLAVE_DEBUG_WAIT and run strace -o /tmp/kdeinit -f -ff -t kdeinit The right kio_http strace will then be somewhere among the kdeinit.<pid> files in /tmp :) Cheers, Waldo
Created attachment 714 [details] kio_http strace Ah, stupid me---I tried strace -f -ff -F on kio_http ;-} Ok, here's a sample file. I didn't believe it but the SIGPIPE is in almost every file I got!
Oh, btw, the trace is in gzip format, I thought this was autodetected.
Michael: can you add a debug output to KExtendedSocket after the getpeername call, that outputs the errno? My guess is the socks library wasn't too happy about the way we call getpeername. As for your connection problems and SIGPIPE, your strace log didn't contain that. The request there succeeded and got a 302 Found reply from the webserver.
The trace doesn't show any trace of socks at all actually. I would expect to see libsocks get dynamically opened.
The problem was that getpeername() call returned -1. That either means that the call is bugged or that the connection has unexpectedly dropped.
Subject: Re: kio_http connection problems with socks Yeah, and I'm sorry, I can't test that anymore as I moved to Australia and I don't have any testbed for that around here. I will try again next year :-}
*** Bug 56948 has been marked as a duplicate of this bug. ***
If you guys need some logs and testing from a real socks environment, tell me and I can run the test from here.
Fixed in both KDE_3_1_BRANCH and HEAD. Please test and reopen this bug report if you still encounter problems.
I'm using KDE 3.1.4 from kde-redhat.sf.net with tsocks (http://tsocks.sourceforge.net/) and I can access everything thru socks. Problem solved for me.