Summary: | dns lookups don't work any more (in konqueror); I'm using an IPv6 DNS server. | ||
---|---|---|---|
Product: | [I don't know] kde | Reporter: | felix-kde |
Component: | general | Assignee: | Thiago Macieira <thiago> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Test-case program |
Description
felix-kde
2004-07-30 00:27:33 UTC
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. |