kern/67819: libc_r's resolver got broken between 2-Jun-2004 and 9-Jun-2004

[Ralf S.Engelschall]

>Number:         67819
>Category:       kern
>Synopsis:       libc_r's resolver got broken between 2-Jun-2004 and 9-Jun-2004
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 11 06:30:08 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Ralf S. Engelschall
>Release:        FreeBSD 4.10-STABLE i386
>Organization:
Engelschall, Germany.
>Environment:
System: FreeBSD en1.engelschall.com 4.10-STABLE FreeBSD 4.10-STABLE #0: Wed Jun 9 09:38:39 CEST 2004 root at en1.engelschall.com:/v/dsk/0/g/usr.src/sys/compile/EN1 i386

>Description:
On 9-Jun-2004 I've upgraded my FreeBSD desktop at home to the latest
4.10-STABLE. After this Mozilla and Opera were no longer able to resolve
any DNS records. I've found that by just replacing /usr/lib/libc_r.so.4
with my backup copy from 4.10-STABLE as of 2-Jun-2004 the two
applications are running fine again. libc.so.4 seems to be not affected,
because only applications linked against libc_r.so.4 seemed to be
broken. So, some MFC to RELENG_4 between 2-Jun-2004 and 9-Jun-2004 has
broken the resolver in libc_r.

>How-To-Repeat:
Use latest 4.10-STABLE and try to run Opera 7.51 or Mozilla 1.6 and
watch them hanging forever displaying "Resolving www.example.com"
after entering http://www.example.com/.

>Fix:
I've not investigated what particular MFC between 2-Jun-2004 and
9-Jun-2004 caused this, but backing out this will certainly fix it
because using the libc_r.so.4 from 2-Jun-2004 fixes the problem
immediately. Sorry, I'm today leaving for holiday so I cannot
investigate myself further, but the problematic MFC should be not too
hard to find as there were not so much MFCs to libc during the mentioned
time range AFAIK.

>Release-Note:
>Audit-Trail:
>Unformatted: