Bug 93729 - hostname lookups behave funny
Summary: hostname lookups behave funny
Status: RESOLVED DUPLICATE of bug 70363
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Stephan Kulow
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-22 18:09 UTC by Charles Samuels
Modified: 2006-03-01 10:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charles Samuels 2004-11-22 18:09:33 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 3.3.5 Debian 1:3.3.5-2
OS:                Linux

Best symptom: sfgate.com takes AGES to load, because it blocks while trying to load ad.doubleclick.net


While it's waiting, the stack is as such:
#0  0x4123c115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#1  0x40f31498 in QWaitCondition::wait () from /opt/qt-copy/lib/libqt-mt.so.3
#2  0x408efb5c in KNetwork::KResolver::wait (this=0x80b3864, msec=0) at kresolver.cpp:496
#3  0x408952f2 in KExtendedSocket::lookup (this=0xbfffd3b0) at kextsock.cpp:745
#4  0x40896011 in KExtendedSocket::connect (this=0xbfffd3b0) at kextsock.cpp:976
#5  0x401d5914 in KIO::TCPSlaveBase::connectToHost () from /opt/kdecvs/lib/libkio.so.4
#6  0x4183a92f in HTTPProtocol::httpOpenConnection (this=0xbfffdad0) at http.cc:1972
#7  0x4183d2b1 in HTTPProtocol::httpOpen (this=0xbfffdad0) at http.cc:2474
#8  0x418329b0 in HTTPProtocol::retrieveHeader (this=0xbfffdad0, close_connection=false)
    at http.cc:498
#9  0x41832844 in HTTPProtocol::retrieveContent (this=0xbfffdad0, dataInternal=false)
    at http.cc:468
#10 0x41836bc4 in HTTPProtocol::get (this=0xbfffdad0, url=@0xbfffd890) at http.cc:1212
#11 0x401e5402 in KIO::SlaveBase::dispatch () from /opt/kdecvs/lib/libkio.so.4
#12 0x401dfa11 in KIO::SlaveBase::dispatchLoop () from /opt/kdecvs/lib/libkio.so.4
#13 0x4182fe08 in kdemain (argc=4, argv=0x8089d60) at http.cc:108
#14 0x0804ccee in launch ()
#15 0x0804e351 in handle_launcher_request ()
#16 0x0804e89d in handle_requests ()
#17 0x0804fa02 in main ()

At stack level #6:
(gdb) print m_state.hostname.ascii()
$4 = 0x80af828 "ad.doubleclick.net"

And, if this helps:
#2  0x408efb5c in KNetwork::KResolver::wait (this=0x80b3864, msec=0) at kresolver.cpp:496
496     KResolverManager::manager()->notifyWaiters.wait(&d->mutex);


Curiously, the only other thread is the linux pthread administrative thread:
(gdb) info thr
  2 Thread 1117186992 (LWP 19003)  0x414e8d25 in poll () from /lib/tls/libc.so.6
  1 Thread 1098325536 (LWP 18989)  0x4123c115 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0


As a workaround, I tried to add the following to my /etc/hosts:
216.73.87.20 ad.doubleclick.net

Which made no difference, thus making me think that bug #57754 is still unfixed.

Please do ask me for any further info you'd like, as this problem has been bothering me for a long time and I'd really like it fixed!
Comment 1 Charles Samuels 2004-11-22 18:28:37 UTC
duplicate. thanks for Maks for pointing out!

*** This bug has been marked as a duplicate of 70363 ***
Comment 2 Thiago Macieira 2004-11-22 20:53:16 UTC
This one doesn't look like a duplicate. Not with that stack trace and thread status.

However, I thought I had foreseen all possible conditions. The use of the mutex makes it impossible for the wait condition to trigger before the main thread starts to wait. Therefore, it seems that somehow the resolvers are not triggering at all.

The problem in bug #70363 is outside KDE: buggy DNS servers forget to reply to some proper, normal DNS queries.