Bug 466786

Summary: Firefox crashes in res_nquery
Product: [Fedora] Fedora Reporter: William Lovaton <walovaton>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: medium    
Version: rawhideCC: danw, drepper, fweimer, gecko-bugs-nobody, jakub, mcepl, phuang, stransky, tomeu, vdanielmo, walters
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-17 14:39:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Full backtrace with debuginfo packages
none
backtrace
none
ip package from Wrieshark
none
crash test none

Description William Lovaton 2008-10-13 16:08:16 UTC 
With the latest rawhide Firefox keeps crashing often at random times with any web page.  I tested this with and without plugins and the result is the same.

I suspect the problem is outside of firefox because I downloaded Firefox 3.0.3 from mozilla.com and it still crashes (even when deleting my ~/.mozilla directory).

I then installed several debuginfo packages with "debuginfo-install firefox" and then ran firefox with the -g option.  When it crashed I executed "thread apply all backtrace" to get a backtrace.  I'll attach it later.

I have to say this bug makes firefox almost unusable for me so I raised the severity to urgent.  This was tested on two laptops running the latest updates from Rawhide (Dell XPS M1210 and a Dell Mini Inspiron 9).
Comment 1 William Lovaton 2008-10-13 16:10:53 UTC 
Created attachment 320196 [details]
Full backtrace with debuginfo packages
Comment 2 Martin Stransky 2008-10-14 06:28:35 UTC 
Can you check if it crashes in the same location? (the res_nquery function in libc). And you're right, it does not seen to be directly connected to firefox...
Comment 3 Martin Stransky 2008-10-14 06:39:11 UTC 
moving to glibc
Comment 4 William Lovaton 2008-10-14 13:23:04 UTC 
I don't know exactly what you are asking but I reproduced the bug several times with debuginfo packages in both laptops and I always saw __libc_res_nquery involved in the trace.  Even before installing debuginfo packages I saw that function in this other trace I posted here:
https://bugzilla.redhat.com/show_bug.cgi?id=463493#c3

Now, let me tell you something else, last night I was browsing the web for a long time with the Dell Mini and Firefox didn't crashed, the difference this time is that I was not using my regular Internet Access (through wireless home router), I was using a broadband GSM connection using a HUAWEI E226 USB Modem.

This is just a hunch, I didn't have time to test it but the thing is that I remember I saw my Dell XPS laptop segfaulting while doing "yum update".  I wonder if it has anything to do with my Internet provider or maybe the wireless adapter.

When I get home tonight I am going to test the following with both laptops:
1) Test with wired connection and see if it crashes.
2) Test with wireless connection and see if it crashes (I know it crashes).
3) Test with broadband GSM connection and see if it crashes.

1 and 2 are with the same Internet provider.
Comment 5 William Lovaton 2008-10-15 02:10:44 UTC 
Well, I just did the test and it seems to confirm my hunch.

Test 1: wired connection... Firefox CRASHED in both laptops
Test 2: wireless connection ... Firefox CRASHED in both laptops
Test 3: broadband GSM connection ... Firefox DIDN'T CRASH in both laptops

Now... what does this mean??

Test 1 and 2 were done with a D-Link wireless ADSL2+ router DSL 2640-T.

I hope this helps even if it sounds really weird.
Comment 6 Ulrich Drepper 2008-10-15 02:29:01 UTC 
(In reply to comment #5)
> Now... what does this mean??

Look at the name servers you use when ADSL is used.  Please provide this information.  Also catch the DNS traffic initiated by firefox (make sure you keep nscd disabled).  Try to replicate the crash using getent:

   getent ahosts whatever
Comment 7 William Lovaton 2008-10-16 03:13:13 UTC 
Damn! I can't get it to crash now.

Primary and secondary DNS server for my ADSL connection are 200.21.200.2 and 200.21.200.79 respectively.

I tried this:
[william@willylaptop ~]$ getent ahosts lwn.net
72.51.34.34     STREAM lwn.net
72.51.34.34     DGRAM  
72.51.34.34     RAW    

Are you saying that I have to try this until it crashes?? Do you need it to happen under GDB??
Comment 8 Ulrich Drepper 2008-10-16 04:37:56 UTC 
(In reply to comment #7)
> Are you saying that I have to try this until it crashes?? Do you need it to
> happen under GDB??

We had some reports similar to this before.  But nobody was able to provide a recipe for reproduction.  It has something to do with the name servers.  At different times you get servers assigned by the DHCP setup.

Once you can reproduce the problem again, record the DNS traffic using tcpdump or wireshark.
Comment 9 Dan Winship 2008-10-20 13:38:26 UTC 
It seems to be caused by non-responsive DNS servers. Eg, right now:

danw@desktop:~> telnet static.pastebin.ca.tbcdn.com
Segmentation fault

(where "telnet" == "random small program that calls getaddrinfo". I originally saw the bug in firefox.)

whois says the nameservers for tbcdn.com are

  208.68.18.110.ip4.sbcdn.com
  208.68.89.40.ip4.sbcdn.com

which resolve to the obvious IP addrs. The former pings but is not answering DNS queries, and the latter does not ping.
Comment 10 Ulrich Drepper 2008-10-20 14:13:24 UTC 
(In reply to comment #9)
> It seems to be caused by non-responsive DNS servers. Eg, right now:
> [...]

OK, that's something I can investigate.
Comment 11 Ulrich Drepper 2008-10-23 04:48:43 UTC 
OK, I cannot reproduce it using the servers mentioned in comment #9 nor with a scenario created here.

The backtrace is not sufficient.  I'd need to see the assembler code and the register content.  I.e., after the crash run in gdb:

  disass $pc-64 $pc+16
  info registers
Comment 12 Matěj Cepl 2008-10-23 06:16:41 UTC 
Reporter, this is just a note from your friendly bugmaster. If you have no clue what comment 11 is talking about, there are some instructions here.

Please also install firefox-debuginfo (debuginfo-install is from
yum-utils package).

	debuginfo-install firefox

Then run firefox with a parameter -g. That will start firefox running inside of gdb debugger. Then use command run and do whatever you did to make firefox crash. When it happens, you should go back to the gdb and run

	(gdb) disass $pc-64 $pc+16
	(gdb) info registers

Copy output of these commands and paste it here as a comment to this bug.

We will review this issue again once you've had a chance to provide us with this information.

Thanks in advance.
Comment 13 Dan Winship 2008-10-23 12:49:20 UTC 
Program received signal SIGSEGV, Segmentation fault.
0x003064f6 in __libc_res_nquery () from /lib/libresolv.so.2
(gdb) disass $pc-64 $pc+16
Dump of assembler code from 0x3064b6 to 0x306506:
0x003064b6 <__libc_res_nquery+422>:	rolb   $0xa8,-0x78f0f402(%ebx)
0x003064bd <__libc_res_nquery+429>:	add    (%eax),%al
0x003064bf <__libc_res_nquery+431>:	add    %al,0x4d8b1b74(%eax,%eax,8)
0x003064c6 <__libc_res_nquery+438>:	sub    %al,-0x79f0f3c7(%ebx)
0x003064cc <__libc_res_nquery+444>:	cwtl   
0x003064cd <__libc_res_nquery+445>:	add    (%eax),%al
0x003064cf <__libc_res_nquery+447>:	add    %cl,0x4539f045(%ebx)
0x003064d5 <__libc_res_nquery+453>:	int3   
0x003064d6 <__libc_res_nquery+454>:	je     0x3069cf <__libc_res_nquery+1727>
0x003064dc <__libc_res_nquery+460>:	mov    %eax,-0x34(%ebp)
0x003064df <__libc_res_nquery+463>:	mov    -0x34(%ebp),%eax
0x003064e2 <__libc_res_nquery+466>:	movzbl 0x3(%eax),%ecx
0x003064e6 <__libc_res_nquery+470>:	mov    %ecx,%edx
0x003064e8 <__libc_res_nquery+472>:	and    $0xf,%edx
0x003064eb <__libc_res_nquery+475>:	mov    %edx,%edi
0x003064ed <__libc_res_nquery+477>:	je     0x3067ac <__libc_res_nquery+1180>
0x003064f3 <__libc_res_nquery+483>:	mov    -0x10(%ebp),%eax
0x003064f6 <__libc_res_nquery+486>:	movzbl 0x3(%eax),%edx
0x003064fa <__libc_res_nquery+490>:	mov    %edx,%eax
0x003064fc <__libc_res_nquery+492>:	and    $0xf,%eax
0x003064ff <__libc_res_nquery+495>:	mov    %al,-0x35(%ebp)
0x00306502 <__libc_res_nquery+498>:	je     0x306848 <__libc_res_nquery+1336>
End of assembler dump.
(gdb) info registers
eax            0x0	0
ecx            0x82	130
edx            0x2	2
ebx            0x312ff4	3223540
esp            0xbfffd5c4	0xbfffd5c4
ebp            0xbfffd868	0xbfffd868
esi            0x1	1
edi            0x2	2
eip            0x3064f6	0x3064f6 <__libc_res_nquery+486>
eflags         0x210202	[ IF RF ID ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
(gdb) q

I tried single-stepping through it before, but optimization was making it impossible for me to figure out what was going on. Lemme build a glibc without optimization...
Comment 14 Jakub Jelinek 2008-10-23 13:26:00 UTC 
0x003064f6 <__libc_res_nquery+486>: movzbl 0x3(%eax),%edx
is
hp2->rcode read in:
        if ((hp->rcode != NOERROR || ntohs(hp->ancount) == 0)
            && (hp2->rcode != NOERROR || ntohs(hp2->ancount) == 0)) {
Clearly hp->rcode could be dereferences, do we know hp != hp2, and from the register contents hp2 == NULL.  That means answerp2 != NULL and *answerp2 == NULL.
Comment 15 Ulrich Drepper 2008-10-24 08:01:45 UTC 
In comment #8 I was also asking for the DNS traffic.  Please run tcpdump or wireshark to record the traffic from and to the DNS server.  We have to know what the boundary condition is which causes the problem.

To make things somewhat manageable make sure there is no other DNS traffic.
Comment 16 Jakub Jelinek 2008-10-24 08:13:41 UTC 
Also, for the c#13 dump, can you just install glibc-debuginfo and when it crashes,
print hp
print hp2
print n
print *nasnwerp2
print *resplen2
?
Comment 17 Dan Winship 2008-10-24 13:46:45 UTC 
Jakub: everything but hp is <value optimized out>.

So it doesn't crash for me every time now either. But here's a tcpdump and strace from when it did:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:06:25.183755 IP (tos 0x0, ttl 64, id 51812, offset 0, flags [DF], proto UDP (17), length 74) 10.68.0.5.55879 > 10.68.0.1.domain: [bad udp cksum a561!] 6763+ A? static.pastebin.ca.tbcdn.com. (46)
18:06:25.184410 IP (tos 0x0, ttl 64, id 51813, offset 0, flags [DF], proto UDP (17), length 74) 10.68.0.5.55879 > 10.68.0.1.domain: [bad udp cksum f36d!] 3586+ AAAA? static.pastebin.ca.tbcdn.com. (46)
18:06:30.225101 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 74) 10.68.0.1.domain > 10.68.0.5.55879: [udp sum ok] 6763 ServFail q: A? static.pastebin.ca.tbcdn.com. 0/0/0 (46)

poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "\214T\1\0\0\1\0\0\0\0\0\0\6static\10pastebin\2ca\5tbcdn\3com\0\0\1\0\1"..., 46, MSG_NOSIGNAL, NULL, 0) = 46
poll([{fd=5, events=POLLIN|POLLOUT}], 1, 6000) = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "\203\321\1\0\0\1\0\0\0\0\0\0\6static\10pastebin\2ca\5tbcdn\3com\0\0\34\0\1"..., 46, MSG_NOSIGNAL, NULL, 0) = 46
poll([{fd=5, events=POLLIN}], 1, 5999)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [46])                = 0
recvfrom(5, "\214T\201\202\0\1\0\0\0\0\0\0\6static\10pastebin\2ca\5tbcdn\3com\0\0\1\0\1"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.68.0.1")}, [16]) = 46
poll([{fd=5, events=POLLIN}], 1, 961)   = 0 (Timeout)
close(3)                                = 0
close(4)                                = 0
close(5)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

It looks like glibc sends the A and AAAA requests, the nameserver returns SRVFAIL for the A, and then glibc times out before the server sends the AAAA response. Doing this repeatedly, if the AAAA response makes it back before glibc times out, then it doesn't crash. (Likewise, if *neither* response makes it back before glibc times out, it doesn't crash either.)

It looks like the problem is that *answerp2 doesn't get filled in in this case (since res_send.c:send_dg() times out and returns before receiving the second response), but send_dg() and thus __libc_res_nsend() still return a non-error value (since *answerp IS filled in), and __libc_res_nquery() assumes the successful return means both *answerp and *answerp2 are valid, and so it does "hp2 = *answerp2;" (where *answerp2 is NULL) and then crashes on "hp2->rcode".
Comment 18 William Lovaton 2008-10-26 19:32:41 UTC 
Sorry, since Oct 15 I have been unable to crash firefox in both rawhide laptops.  Everything have been working fine.
Comment 19 Martin Stransky 2008-10-29 10:31:58 UTC 
*** Bug 463493 has been marked as a duplicate of this bug. ***
Comment 20 Peng Huang 2008-10-30 00:11:44 UTC 
I am using glibc-2.8.90-15.i686. Both firefox and yum always crash in my laptop.
Comment 21 Peng Huang 2008-10-30 00:19:37 UTC 
Created attachment 321885 [details]
backtrace
Comment 22 Ulrich Drepper 2008-10-30 00:24:19 UTC 
(In reply to comment #20)
> I am using glibc-2.8.90-15.i686. Both firefox and yum always crash in my
> laptop.

Capture the DNS traffic with wireshark and show the DNS servers used.  This is highly dependent on the actual DNS situation and probably the of a DNS server responding incorrectly or not at all etc.
Comment 23 Peng Huang 2008-10-30 00:25:18 UTC 
I hacked the code. I found hp2 is 0x00 on line 262.
261	
262		if ((hp->rcode != NOERROR || ntohs(hp->ancount) == 0)
263		    && (hp2->rcode != NOERROR || ntohs(hp2->ancount) == 0)) {
264	#ifdef DEBUG
265			if (statp->options & RES_DEBUG) {
266				printf(";; rcode = %d, ancount=%d\n", hp->rcode,
Comment 24 Ulrich Drepper 2008-10-30 00:26:52 UTC 
(In reply to comment #22)
> Capture the DNS traffic with wireshark and show the DNS servers used.  This is
> highly dependent on the actual DNS situation and probably the of a DNS server
> responding incorrectly or not at all etc.


Oh, and in gdb, for the thread in __res_nquery, the register content and assembler output as explained in comment #12.
Comment 25 Peng Huang 2008-10-30 00:36:19 UTC 
(gdb) disassemble $pc-64 $pc+16
Dump of assembler code from 0xa094aa to 0xa094fa:
0x00a094aa <__libc_res_nquery+410>:	or     -0xfba7700(%ebx),%ecx
0x00a094b0 <__libc_res_nquery+416>:	jg     0xa097a8 <__libc_res_nquery+1176>
0x00a094b6 <__libc_res_nquery+422>:	mov    0x2c(%ebp),%edx
0x00a094b9 <__libc_res_nquery+425>:	mov    (%edx),%eax
0x00a094bb <__libc_res_nquery+427>:	cmp    $0xc,%eax
0x00a094be <__libc_res_nquery+430>:	jle    0xa097ad <__libc_res_nquery+1181>
0x00a094c4 <__libc_res_nquery+436>:	mov    -0x10(%ebp),%ecx
0x00a094c7 <__libc_res_nquery+439>:	cmp    %ecx,-0x34(%ebp)
0x00a094ca <__libc_res_nquery+442>:	je     0xa099cd <__libc_res_nquery+1725>
0x00a094d0 <__libc_res_nquery+448>:	mov    %ecx,-0x34(%ebp)
0x00a094d3 <__libc_res_nquery+451>:	mov    -0x34(%ebp),%eax
0x00a094d6 <__libc_res_nquery+454>:	movzbl 0x3(%eax),%ecx
0x00a094da <__libc_res_nquery+458>:	mov    %ecx,%edx
0x00a094dc <__libc_res_nquery+460>:	and    $0xf,%edx
0x00a094df <__libc_res_nquery+463>:	mov    %edx,%edi
0x00a094e1 <__libc_res_nquery+465>:	je     0xa097ec <__libc_res_nquery+1244>
0x00a094e7 <__libc_res_nquery+471>:	mov    -0x10(%ebp),%eax
0x00a094ea <__libc_res_nquery+474>:	movzbl 0x3(%eax),%edx
0x00a094ee <__libc_res_nquery+478>:	mov    %edx,%eax
0x00a094f0 <__libc_res_nquery+480>:	and    $0xf,%eax
0x00a094f3 <__libc_res_nquery+483>:	mov    %al,-0x35(%ebp)
0x00a094f6 <__libc_res_nquery+486>:	je     0xa09840 <__libc_res_nquery+1328>
End of assembler dump.

(gdb) info registers
eax            0x0	0
ecx            0x82	130
edx            0x2	2
ebx            0xa15ff4	10575860
esp            0xadafb804	0xadafb804
ebp            0xadafbaa8	0xadafbaa8
esi            0x1	1
edi            0x2	2
eip            0xa094ea	0xa094ea <__libc_res_nquery+474>
eflags         0x206	[ PF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
Comment 26 Peng Huang 2008-10-30 00:56:03 UTC 
Created attachment 321888 [details]
ip package from Wrieshark

It is an IP packages dump from another firefox crash.
Comment 27 Dan Winship 2008-10-30 13:51:16 UTC 
Created attachment 321934 [details]
crash test

Try this. It should crash 100% reliably.

(69.25.196.35:53000 is running a nameserver that returns SERVFAIL to any A query, and "takes a really long time to respond" (ie, never responds) to any AAAA query, qv comment #17.)
Comment 28 Ulrich Drepper 2008-10-30 17:02:57 UTC 
I have changed the upstream code.  The next rawhide build will have it.  Please retest when it becomes available.
Comment 29 Jakub Jelinek 2008-11-07 13:51:54 UTC 
This is all in glibc-2.8.90-16 in rawhide.
Comment 30 Tomeu Vizoso 2011-06-06 13:55:16 UTC 
(In reply to comment #27)
> Created attachment 321934 [details]
> crash test
> 
> Try this. It should crash 100% reliably.
> 
> (69.25.196.35:53000 is running a nameserver that returns SERVFAIL to any A
> query, and "takes a really long time to respond" (ie, never responds) to any
> AAAA query, qv comment #17.)

This test case is failing again here with glibc-2.14-1.i686, this is what gdb says:

[tomeu@rekvicka (master) clutter]$ gcc -g test.c -o test
[tomeu@rekvicka (master) clutter]$ gdb ./test
GNU gdb (GDB) Fedora (7.2.90.20110525-38.fc15)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tomeu/bosch-jhbuild/source/clutter/test...done.
(gdb) set he 0
(gdb) r
Starting program: /home/tomeu/bosch-jhbuild/source/clutter/test 

Program received signal SIGSEGV, Segmentation fault.
__libc_res_nquery (statp=0x44ba2c00, name=0xbfffd427 "anything.", class=1, type=62321, answer=0xbfffdcd0 "", 
    anslen=2048, answerp=0xbfffe8fc, answerp2=0xbfffe900, nanswerp2=0xbfffe904, resplen2=0xbfffe908)
    at res_query.c:263
263		    && (hp2->rcode != NOERROR || ntohs(hp2->ancount) == 0)) {
Missing separate debuginfos, use: debuginfo-install nss-mdns-0.10-9.fc15.i686
(gdb) bt f
#0  __libc_res_nquery (statp=0x44ba2c00, name=0xbfffd427 "anything.", class=1, type=62321, 
    answer=0xbfffdcd0 "", anslen=2048, answerp=0xbfffe8fc, answerp2=0xbfffe900, nanswerp2=0xbfffe904, 
    resplen2=0xbfffe908) at res_query.c:263
        hp = 0xbfffdcd0
        n = 0
        use_malloc = 0
        oflags = 0
        bufsize = <optimized out>
        buf = <optimized out>
        query1 = 0xbfffd180 "#p\001"
        nquery1 = <optimized out>
        query2 = 0xbfffd19c "\017\330\001"
        nquery2 = 26
        hp2 = 0x0
#1  0x44d82365 in __libc_res_nquerydomain (statp=0x44ba2c00, name=<optimized out>, domain=0x44ba2c60 "", 
    class=1, type=62321, answer=0xbfffdcd0 "", anslen=2048, answerp=0xbfffe8fc, answerp2=0xbfffe900, 
    nanswerp2=0xbfffe904, resplen2=0xbfffe908) at res_query.c:578
        nbuf = "anything.", '\000' <repeats 580 times>, "\005\020\240D\223\272\242DS\270\327D\002\000\000\000\304_\241DDɡD\001\000\000\000\350\366\377\267\244\026\240D", '\000' <repeats 24 times>, "\003\000\000\000\363\003\000\000\310\325Č\000\000\000\000\256&f\004\000\000\000\000dM\242D\024ΡD\000\000\000\000\000\000\000\000\350\366\377\267", '\000' <repeats 16 times>, "\001\000\000\000\365\a\000\000h\270\004\b8\364\377\267\273\261\327D\244`\242DH\251\327D\001\000\000\000\304_\241D\020\266\004\b\f\330\377\277\344\327\377\277L\031\240D\320\327\377\277H\251\327D\270\327\377\277Tj\241D\000\000\000\000h\270\004\b\001\000\000\000\000\000\000\000\001\000\000\000X\264\004\b", '\000' <repeats 48 times>, "\f\330\377\277", '\000' <repeats 12 times>, "X\264\004\b\000\000\000\000\000\000\000\000\273\261\327D", '\000' <repeats 32 times>, "dM\242D8\364\377\267", '\000' <repeats 16 times>"\377"...
        longname = 0xbfffd427 "anything."
        n = <optimized out>
        d = <optimized out>
#2  0x44d825e5 in __libc_res_nsearch (statp=0x44ba2c00, name=0x804863d "anything", class=1, type=62321, 
    answer=0xbfffdcd0 "", anslen=2048, answerp=0xbfffe8fc, answerp2=0xbfffe900, nanswerp2=0xbfffe904, 
    resplen2=0xbfffe908) at res_query.c:416
        done = <optimized out>
        cp = <optimized out>
        domain = <optimized out>
        hp = 0xbfffdcd0
        tmp = "D\030\024\272D`\000\000\000\r\000\000\000\001\000\000\000\000\000\000\000x", '\000' <repeats 15 times>, "\r\000\000\000\071\000\000\000\340\023\272D[\000\000\000n\000\000\000w\000\000\000|\000\000\000\364\377\271D`\000\000\000\340\023\272Dl\352\377\277\345ڨD", '\000' <repeats 12 times>"\364, \377\271D \331\377\277`\000\000\000l\352\377\277I\225\261D`\000\000\000\034\352\377\277", '\000' <repeats 17 times>, "@\000\000\003\000\000\000\376\200\000\000\000\000\000\000\002\023\350\377\376\063\237kP\331\377\277", '\000' <repeats 21 times>"\200, \000\000\001", '\000' <repeats 18 times>, "\001\200\331\377\277", '\000' <repeats 21 times>, "\030\000\000\003", '\000' <repeats 13 times>"\377, \377\300\250\n\006\260\331\377\277", '\000' <repeats 21 times>, "\b\257D\001", '\000' <repeats 13 times>"\377, \377\177\000\000\001\000\000\000\000"...
        dots = <optimized out>
        trailing_dot = <optimized out>
        ret = <optimized out>
        saved_herrno = -1
        got_nodata = <optimized out>
        got_servfail = <optimized out>
        root_on_list = 1
        tried_as_is = 0
        searched = 1
#3  0x001243e9 in _nss_dns_gethostbyname4_r (name=0x804863d "anything", pat=0xbfffea7c, buffer=0x804a788 "", 
    buflen=1024, errnop=0xbfffea80, herrnop=0xbfffea8c, ttlp=0x0) at nss_dns/dns-host.c:314
        host_buffer = {buf = 0xbfffdcd0, ptr = 0xbfffdcd0 ""}
        orig_host_buffer = 0xbfffdcd0
        ans2p = 0x0
        nans2p = 0
        resplen2 = 0
        olderr = 0
        status = <optimized out>
        n = <optimized out>
#4  0x44ad7d73 in gaih_inet (name=0x804863d "anything", service=<optimized out>, req=0xbfffebf0, 
    pai=0xbfffeba0, naddrs=0xbfffebb0) at ../sysdeps/posix/getaddrinfo.c:848
        herrno = 1
        fct4 = 0x124320 <_nss_dns_gethostbyname4_r>
        pat = 0xbfffea7c
        no_inet6_data = <optimized out>
        nip = 0x804a3c0
        status = <optimized out>
        no_more = <optimized out>
        old_res_options = 524993
        tmpbuflen = 1024
        no_data = 0
        inet6_status = <optimized out>
        tp = <optimized out>
        st = 0xbfffe9d0
        at = 0xbfffe960
        rc = 0
        got_ipv6 = <optimized out>
        canon = 0x0
        orig_name = 0x804863d "anything"
        alloca_used = 144
        port = <optimized out>
        malloc_name = false
        malloc_addrmem = false
        addrmem = 0x0
        malloc_canonbuf = <optimized out>
        canonbuf = <optimized out>
        malloc_tmpbuf = false
        tmpbuf = 0x804a788 ""
        result = 0
#5  0x44adb20d in getaddrinfo (name=0x804863d "anything", service=<optimized out>, hints=0xbfffebf0, 
    pai=0xbfffebec) at ../sysdeps/posix/getaddrinfo.c:2395
        i = 0
        last_i = 0
        nresults = 0
        p = 0x0
        gaih_service = {name = 0x0, num = 0}
        pservice = <optimized out>
        local_hints = {ai_flags = 134514234, ai_family = 1151468884, ai_socktype = -1207962568, 
          ai_protocol = 0, ai_addrlen = 1153040372, ai_addr = 0xbfffeba7, ai_canonname = 0x804863a "35", 
          ai_next = 0xffffffff}
        in6ai = 0x804a008
        in6ailen = 4
        seen_ipv4 = true
        seen_ipv6 = true
        end = 0xbfffeba0
        naddrs = 0
#6  0x08048537 in main (argc=1, argv=0xbfffecb4) at test.c:17
        hints = {ai_flags = 0, ai_family = 0, ai_socktype = 0, ai_protocol = 0, ai_addrlen = 0, 
          ai_addr = 0x0, ai_canonname = 0x0, ai_next = 0x0}
        res = 0x8048571
(gdb) disass $pc-64,$pc+16
Dump of assembler code from 0x44d81f71 to 0x44d81fc1:
   0x44d81f71 <__libc_res_nquery+753>:	and    $0xc,%al
   0x44d81f73 <__libc_res_nquery+755>:	mov    %ecx,0x10(%esp)
   0x44d81f77 <__libc_res_nquery+759>:	mov    -0x24(%ebp),%ecx
   0x44d81f7a <__libc_res_nquery+762>:	mov    %ecx,0x8(%esp)
   0x44d81f7e <__libc_res_nquery+766>:	mov    0x8(%ebp),%ecx
   0x44d81f81 <__libc_res_nquery+769>:	mov    %ecx,(%esp)
   0x44d81f84 <__libc_res_nquery+772>:	call   0x44d80f40 <__res_nopt>
   0x44d81f89 <__libc_res_nquery+777>:	mov    -0x40(%ebp),%edx
   0x44d81f8c <__libc_res_nquery+780>:	test   %eax,%eax
   0x44d81f8e <__libc_res_nquery+782>:	mov    %eax,%esi
   0x44d81f90 <__libc_res_nquery+784>:	setle  %cl
   0x44d81f93 <__libc_res_nquery+787>:	test   %cl,%cl
   0x44d81f95 <__libc_res_nquery+789>:	jne    0x44d81f18 <__libc_res_nquery+664>
   0x44d81f97 <__libc_res_nquery+791>:	jmp    0x44d81d70 <__libc_res_nquery+240>
   0x44d81f9c <__libc_res_nquery+796>:	lea    0x0(%esi,%eiz,1),%esi
   0x44d81fa0 <__libc_res_nquery+800>:	movzwl 0x6(%eax),%edi
   0x44d81fa4 <__libc_res_nquery+804>:	ror    $0x8,%di
   0x44d81fa8 <__libc_res_nquery+808>:	test   %di,%di
   0x44d81fab <__libc_res_nquery+811>:	jne    0x44d81e70 <__libc_res_nquery+496>
=> 0x44d81fb1 <__libc_res_nquery+817>:	movzbl 0x3(%ecx),%edx
   0x44d81fb5 <__libc_res_nquery+821>:	mov    %dl,-0x1c(%ebp)
   0x44d81fb8 <__libc_res_nquery+824>:	and    $0xf,%edx
   0x44d81fbb <__libc_res_nquery+827>:	mov    %dl,-0x24(%ebp)
   0x44d81fbe <__libc_res_nquery+830>:	jne    0x44d81e33 <__libc_res_nquery+435>
End of assembler dump.
(gdb) info registers
eax            0xbfffdcd0	-1073750832
ecx            0x0	0
edx            0x0	0
ebx            0x44d90ff4	1155076084
esp            0xbfffd154	0xbfffd154
ebp            0xbfffd3f0	0xbfffd3f0
esi            0x0	0
edi            0x0	0
eip            0x44d81fb1	0x44d81fb1 <__libc_res_nquery+817>
eflags         0x210246	[ PF ZF IF RF ID ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
(gdb) 

Another consequence is that telnet always crashes at startup.