Bug 155157 - "Unknown Error" when using HTTP or POP3 KIO slave
Summary: "Unknown Error" when using HTTP or POP3 KIO slave
Status: RESOLVED DUPLICATE of bug 162600
Alias: None
Product: kdelibs
Classification: Unclassified
Component: general (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR normal with 30 votes (vote)
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 155464 155670 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-01-05 21:02 UTC by Jon
Modified: 2008-07-12 20:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Konsole output from QT_FATAL_WARNINGS=1 konqueror (12.58 KB, text/plain)
2008-01-06 05:06 UTC, Jon
Details
konq-more-konsole-output.txt (19.83 KB, text/plain)
2008-01-06 22:34 UTC, Jon
Details
kdeinit4-output.txt (27.62 KB, text/plain)
2008-01-07 02:50 UTC, Jon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jon 2008-01-05 21:02:13 UTC
Version:           4.00.00 (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc version 4.2.2 (Gentoo 4.2.2 p1.0) 
OS:                Linux

I compiled KDE from the kde 4.0.0 tag in the svn. I kept KDE 3.5.8 on my system, and I use a clean $KDEHOME for KDE4. My problem is with Konqueror not being able to access almost any website. I can access google.com and do searches, but when I type www.gentoo.org or www.kde.org, I get the follow error message (same for kde and other sites, but with that site's url):
An error occurred while loading http://www.gentoo.org/:
Could not connect to host www.gentoo.org: Unknown error.

There are very few websites that I can actually see. I didn't know if I should post this in Konq or for KIOSlave, because I don't know what kind of problem it is.

I have been talking with Dmitry (dimichxp) on IRC and he says that he got this error once, but could not reproduce it again, so I did something that makes this error happen everytime for me. I am typing this bug report in Opera and I have no issues at all with any webpage. So, it is a html thing specific to whatever Konq uses.

Also, I did some testing and it seems to be only a http specific thing, because ftp://ftp.kde.org/pub/kde/stable/3.5.8/src/ works just fine. Then I tried a sub domain of kde.org like ftp is a sub domain, and I found that http://techbase.kde.org/ does _not_ work. So, it is not a domain thing where the domain of kde.org does not work, but only the http part that does not work.

That sounds a bit confusing. I would appreciate any help.

Thanks.
Comment 1 Jon 2008-01-06 04:51:43 UTC
II recompiled qt, kdelibs, and kdebase with debug info and it would still not output any errors to .xsession-errors. I made sure the appropriate items were checked in kdebugdialog like thiago suggested on IRC.

Is there any way I can trace what is going on and why the http part is failing? I have the debug symbols now, so can I use that to my advantage? I don't know what else to do.

Thanks.
Comment 2 Jon 2008-01-06 05:06:33 UTC
Created attachment 22864 [details]
Konsole output from QT_FATAL_WARNINGS=1 konqueror

I ran konq with this command just now:
QT_FATAL_WARNINGS=1 konqueror and I got a crash dialog. I will post everything
I got. First the crash dialog since it's small:
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
...
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xa63a9b40 (LWP 19342)]
(no debugging symbols found)
...
(no debugging symbols found)
0xa7f26410 in __kernel_vsyscall ()
[Current thread is 0 (process 19342)]

Thread 1 (Thread 0xa63a9b40 (LWP 19342)):
#0  0xa7f26410 in __kernel_vsyscall ()
#1  0xa7d8d356 in nanosleep () from /lib/libc.so.6
#2  0xa7d8d17c in sleep () from /lib/libc.so.6
#3  0xa786564e in ?? () from /usr/kde/svn/lib/libkdeui.so.5
#4  0x00000001 in ?? ()
#5  0x00000000 in ?? ()
#0  0xa7f26410 in __kernel_vsyscall ()

The info from Konsole is in the attachment. It's a lot of text, so I put it in
a text file. Normally, I just start Konq from the menu, but this time I got the
idea to run it with the above command when I say the topic of #kde4-krush
channel.

I hoep it helps.
Comment 3 Jon 2008-01-06 22:34:38 UTC
Created attachment 22878 [details]
konq-more-konsole-output.txt

By request from tmg from IRC, I attached the out from Konq without the
QT_FATAL_WARNINGS=1 part. Hope this helps.
Comment 4 Jon 2008-01-07 02:50:29 UTC
Created attachment 22884 [details]
kdeinit4-output.txt

maelcum on IRC wanted me to post this. This is the output taken from running
kdeinit4 in the terminal and then launched konq to try to access the website.
Comment 5 Jon 2008-01-07 20:07:46 UTC
maelcum wanted me to use the debugger to try to figure out where the everything is broken. I ran the command: KDE_SLAVE_DEBUG_WAIT=http kdeinit4 and eventually came to the part where I could open the debugger. I first tried gdb, but I kept getting weird errors and thing broke. I wanted to see what was going on, so I rean the test again, but I used insight, which has the same code as gdb and made by the same people, I think. Anyways, this is what happened in screenshot form.

Once I started with: insight kdeinit4 15305, I would come to a this screen:
http://img184.imageshack.us/my.php?image=insight1yq0.png

I then clicked the button for continue just to see what would happen, and I would get this:
http://img184.imageshack.us/my.php?image=insight2md9.png

The source window would stay the same. The code did not move at all.

Next I opened a insight console window and typed c for continue, and this is what I saw:
http://img170.imageshack.us/my.php?image=insight3bo8.png

The browser would return that it could not find the webiste, and insight would be running continually. I had to click the stop button in order to do anything. It was stuck in some kind of infinite loop. But the browser was finished.

I had the ability to move up in the stack, so I did. I click the move up the stack button once, so this is the call right before the code in screenshot 1:
http://img231.imageshack.us/my.php?image=insight4lt5.png

Then I click the button to take me to the bottom of the stack and it would be the same window as screenshot 1.

What is going on? Did I do something in correctly? I would appreciate any suggestions that I could do differently to help debug this right.
Comment 6 Thomas McGuire 2008-01-08 23:09:32 UTC
Reassigning to kdelibs, as this is probably a issue with KTCPSlaveBase.

I also know someone who has the same problem ("Unknown Error") with the POP3 KIO slave. Seems to be the same issue.

A similar bug is bug 155157, which I also can't reproduce (but others can) and which should be fixed with the recent KTcpSocket workaround anyway. Strange. 
Comment 7 Andreas Hartmetz 2008-01-09 08:51:48 UTC
May or may not be a duplicate of Bug 155043. I had the reporter run objdump -d -t on the libkdecore.so in his KDE4 library path to make sure that he really does have the version of KTcpSocket in kdelibs that works around a Qt bug regarding incorrect handling of infinite timeouts.
Subsequently added debug output in kdelibs strongly suggests a different Qt bug being involved as everything in kdelibs looked as expected, except for unexpected timeout errors after QSslSocket::waitForConnected. The Qt version was 4.3.3 IIRC. One thing to investigate is how the behavior of QAbstractSocket to qobject_cast<>() itself up to QSslSocket in some cases may play a role here. It shouldn't change anything however, if nothing else because KTcpSocket does not inherit QAbstractSocket but only QIODevice.

I think we really need a trace of QSslSocket::waitForConnected() to find out where it fails and whether it's a plain bug, a configuration problem or whatever else.
Comment 8 Jon 2008-01-10 03:18:51 UTC
I was able to get a little further into the debugging process. After making starting kdeinit4 with the command I listed in the previous posting, I came to the debug part of the output after typing in www.kde.org. Normally in previous tasks, I just pressed c for continue and I didn't get very far. However, after pressing c once, I I then started to press n for next and I got a bit further into the code. This is the output:

(gdb) break QTcpSocket::waitForConnected()
Function "QTcpSocket::waitForConnected()" not defined.
Breakpoint 1 (QTcpSocket::waitForConnected()) pending.

(gdb) c
Continuing.

Program received signal SIGSTOP, Stopped (signal).
[Switching to Thread 0xa65f76d0 (LWP 18306)]
0xa7ef0410 in __kernel_vsyscall ()

(gdb) n
Single stepping until exit from function __kernel_vsyscall, 
which has no line number information.

Program received signal SIGSTOP, Stopped (signal).
0xa7ef0410 in __kernel_vsyscall ()

(gdb) n
Single stepping until exit from function __kernel_vsyscall, 
which has no line number information.
0xa68befb6 in kill () from /lib/libc.so.6

(gdb) n
Single stepping until exit from function kill, 
which has no line number information.
launch (argc=4, _name=0x807ae64 "kio_http", args=0x807aed9 "", cwd=0x0, envc=0, envs=0x807aede "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x80511e1 "0") at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kinit/kinit.cpp:615

(gdb) n
[New Thread 0xa631db90 (LWP 18427)]

Program received signal SIGINT, Interrupt.
0xa7ef0410 in __kernel_vsyscall ()

It was here when konq reuturned that that error message that I keep getting. Insight was in some kind of processing loop and would not return. I had to press the stop button in order to gain control back. I have a screenshot of the of insight code part. This is the last thing of code right when Konq returns the error. I should have screenshoted the previous page maybe.
http://img149.imageshack.us/my.php?image=insight5no9.png
Here it would not return at all. You see the stop button? Is the code in some kind of infinite loop that is keeping insight from returning after executing that? After returning I decided to press n again to see what would happen, but it's just pop commands indicating that the function is exiting.

(gdb) n
Single stepping until exit from function __kernel_vsyscall, 
which has no line number information.
0xa6968511 in select () from /lib/libc.so.6

(gdb)

Does any of this output help?
Comment 9 Klaus Dimde 2008-01-10 16:25:01 UTC
I think this bug is the same as #154774 perhaps my finding there can help too
Comment 10 Thomas McGuire 2008-01-12 18:38:42 UTC
*** Bug 155464 has been marked as a duplicate of this bug. ***
Comment 11 Tommi Tervo 2008-01-14 09:03:37 UTC
*** Bug 155670 has been marked as a duplicate of this bug. ***
Comment 12 Thibaut Cousin 2008-01-14 09:12:43 UTC
I reported a bug which seems to be a duplicate of this one. I can't be as technical as some other comments above, but here's what I can say to try to help...

I hit the bug in Konqueror and also KGet when trying to use plain HTTP: port 80, no proxy at all, etc. No error reported to .xsession-errors.

While Konqueror times out with the "Unknown error" message, KGet never spits out any error and just sits there, waiting for hours to establish a connection that never happens.

Can I do anything to help debug this?
Comment 13 Pavel Zheltobryukhov 2008-01-20 21:39:06 UTC
I founded that opening http:// or ftp:// get "Unknown error", but smb:// works!
And if I open one of my smb:// resources in Konqueror first of all, the http:// and ftp:// begining to work in other new Konqueror tabs and windows.

I couldn't explain this, but (may be) this information will be useful.
Comment 14 Pavel Zheltobryukhov 2008-01-21 20:56:10 UTC
Oh, the opening of smb:// resource first is not a solution. In my case, Konqueror begin to work then I start OpenVPN tunnel to my work. The same situation mentioned here:
 https://bugs.kde.org/show_bug.cgi?id=154774#c15
Comment 15 Pavel Zheltobryukhov 2008-01-28 08:19:07 UTC
*** This bug has been confirmed by popular vote. ***
Comment 16 Thibaut Cousin 2008-02-06 20:37:39 UTC
I've just upgraded to KDE 4.0.1 with OpenSUSE packages. The problem is still there... Konqueror and KGet are completely unusable for the moment.

Are there any progress on this problem? I'm willing to test any patch if need be.
Comment 17 Pavel Zheltobryukhov 2008-02-06 20:49:46 UTC
Thibaut, look at the Bug 154774. Try the solution described there. May be, it will help to you.
Comment 18 Thibaut Cousin 2008-02-06 21:05:26 UTC
Thank you for the link.

Indeed, using real DNS addresses works around the problem, but doesn't solve it... All other existing browsers, including Konqueror 3, don't need that kind of tweaking.

I can start using Konqueror 4 now, but I'm still hoping there will be a real fix soon. :)
Comment 19 Thomas McGuire 2008-07-12 20:37:37 UTC

*** This bug has been marked as a duplicate of 162600 ***