Version: (using KDE KDE 3.2.92) Installed from: Gentoo Packages Compiler: gcc 3.4.1 OS: Linux Here is my /etc/resolv.conf: nameserver fec0:0:0:ffff::1 That is an IPv6 anycast address. It means my computer will work on any network that has an IPv6 nameserver at this (standardized) address. I'm using this setup on all my stationary and portable computers, so I never have to touch my DNS settings. glibc supports this. kde always used glibc to do DNS resolving. Now kde apparently wrote a separate DNS implementation, which happens to not support IPv6. This is a complete show-stopper for me. Please at least give me a way to revert to the glibc DNS resolver as in KDE beta 1.
Here's my /etc/resolv.conf: nameserver fec0:0:0:8000:200:21ff:fe69:43a7 It's working. KDE is using the glibc implementation. Your bug report is completely unfounded. What's more, nothing in the name-resolving code changed between KDE 3.3 beta 1 and beta 2. I don't doubt that you're having problems, but you're laying blame at the wrong place. Can you provide a more detailed description to your problem? Was there any DNS traffic? Re-installing KDE 3.3 beta 1 solves the problem?
Does KDE 3.3 rc1 or rc2 fix the problem?
Has there been any new development with your problem?
kde 3.3 has the same problem for me. I'm not using a proxy. I previously had this only with firefox, now KDE is affected as well. Has anything changed in the DNS resolver routines between kde 3.2.3 and kde 3.3?
A lot has changed between 3.2.3 and 3.3. However, the backend itself is still the same: glibc's getaddrinfo(3) function.
Hello, I believe I have found the cause for this bug. Are you using an NPTL-enabled glibc? If you are, it could be the same bug I am experiencing now.
Yes, I am using NPTL glibc. And now that you mention it, the problems started on my desktop (with Firefox as well, actually) as soon as I enabled NPTL. Then, further down the road, I enabled NPTL approximately at the same time I started having problems on my notebook. Hooray, we finally have some progress in nailing this bug!
Created attachment 7813 [details] Test-case program Please compile (gcc -o /tmp/test /tmp/test.c -lpthread) the attached program and run it. In an NPTL environment, I get: (4097fbb0) Results from getaddrinfo(af = 2): 0 (4097fbb0) Results from getaddrinfo(af = 2): -3 While in a non-NPTL environment, I get: (4002) Results from getaddrinfo(af = 2): 0 (8003) Results from getaddrinfo(af = 2): 0 Notice the error in the second attempt in the first run. Please also paste the results from: strace -ff /tmp/test2>&1 | grep 'connect.*53' If we confirm that you have the same bug as I do, then it's a glibc bug. I'll close this bug report here and we'll report it somewhere else. I plan on debugging libresolv when I have the time, however.
Bug has been reported to the NPTL maintainer: http://sources.redhat.com/bugzilla/show_bug.cgi?id=434 I am now working on a workaround/fix for KDE code.
CVS commit by thiago: Adding a workaround/fix for the problem mentioned in bug #86271. In fact, the bug is in glibc+NPTL code and affects very few users -- myself included: only those that use IPv6 DNS servers. See http://sources.redhat.com/bugzilla/show_bug.cgi?id=434 for information on the bug itself. This fix makes the name-resolving threads wait around forever, instead of exiting after 20 seconds of inactivity. CCMAIL:86271@bugs.kde.org M +1 -1 kresolvermanager.cpp 1.31 --- kdelibs/kdecore/network/kresolvermanager.cpp #1.30:1.31 @@ -205,5 +205,5 @@ public: // maxThreadWaitTime milliseconds between each attempt. After that, it'll // exit -static const int maxThreadWaitTime = 20000; // 20 seconds +static const int maxThreadWaitTime = ULONG_MAX; // wait forever static const int maxThreads = 5;
CVS commit by thiago: Backport of the fix that went into r1.31. See Bug #86271 for information. CCMAIL:86271-done@bugs.kde.org M +1 -1 kresolvermanager.cpp 1.28.2.2 --- kdelibs/kdecore/network/kresolvermanager.cpp #1.28.2.1:1.28.2.2 @@ -204,5 +204,5 @@ public: // maxThreadWaitTime milliseconds between each attempt. After that, it'll // exit -static const int maxThreadWaitTime = 20000; // 20 seconds +static const int maxThreadWaitTime = ULONG_MAX; // wait forever static const int maxThreads = 5;
Bug has been fixed upstream, in glibc's CVS: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/resolv/res_init.c.diff?r1=1.40&r2=1.41&cvsroot=glibc Please ask your distributor to upgrade glibc or apply this patch.
CVS commit by thiago: Committing the fix for bug #91936. This is fairly intrusive, so some more testing is required before this change is backported into the 3.3.x branch. I need especially people with older systems and non-Linux systems to test it. This patch also adds another workaround for bug #86271, in the sense that res_init is always called in glibc-based systems once a thread is started. But note that the proper fix is to upgrade glibc, since other non-KDE programs are affected by the same bug (notably, Mozilla). Also, please notify me of any other systems that use a thread-specific resolver context (the `res' variable), like glibc. CCBUG: 86271 BUG: 91936 M +37 -16 kresolver_p.h 1.15 M +78 -29 kresolvermanager.cpp 1.32 M +145 -124 kresolverstandardworkers.cpp 1.13 M +23 -2 kresolverworkerbase.cpp 1.8 M +29 -3 kresolverworkerbase.h 1.8
The workaround has been reverted. Make sure your glibc has been upgraded to fix the real bug.