Bug 155157

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.

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.

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.

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.

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.

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. 

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.

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?

I think this bug is the same as #154774 perhaps my finding there can help too

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

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

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?

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.

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

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

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.

Thibaut, look at the Bug 154774. Try the solution described there. May be, it will help to you.

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. :)

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