Date: 3 Mar 1999 12:51:15 +1100 From: "John Saunders" <john.saunders@nlc.net.au> To: freebsd-bugs@freebsd.org Cc: Michael Fuhr <mfuhr@dimensional.com> Subject: Re: bin/10344: Core dump in gethostbyaddr for 199.93.70.2 Message-ID: <19990303015115.18731.qmail@nhj.nlc.net.au> In-Reply-To: <19990302041744.B29139@flatland.dimensional.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I compiled the file gethostbydns.c from the src/lib/libc/net directory without -O and statically linked that with dnsserver. In this case the domain problem was handled and the process didn't dump core. However if I compiled that file with -O the exact same behaviour occured as when everything was linked against libc. I'm going to do a build world of my system without -O and see how that goes. But for now I'm 99% convinced it's a compiler issue. In nlc.lists.freebsd-bugs you wrote: > On Tue, Mar 02, 1999 at 12:00:02AM -0800, Bill Fenner wrote: >> Aha! I must be using a name server that's truncating - I only got >> 14 answers. If I set my name server to monster.nlc.net.au, I get >> lots of answers and a core dump. tcpdump shows that the clean 14 >> answers come in a UDP packet and then it opens a TCP connection. >> "dig" says that the TCP response is malformed. Since "dig" complains >> about a malformed packet instead of dumping core, that might be a >> better place to start to try to figure out what's going on. (The >> header claims to contain 810 answers but dig only prints 272 before >> printing an error. The 24k of data on the wire contains much more >> than dig displays, but I don't have a good way of telling whether >> or not it's really malformed.) > I wrote a Perl script using Net::DNS to query the zone's primary > nameserver (apparently shields.burlee.com, 199.93.70.3) and got the > following: > ;; ANSWER SECTION (810 records) > Deep recursion on subroutine "Net::DNS::Packet::dn_expand" > at /usr/local/lib/perl5/site_perl/5.005/Net/DNS/Packet.pm line 614. > Out of memory! > After adding a check for loops in the DNS name compression mechanism, > I discovered that the first record in the answer section has a loop: > Field > Offset : Data > Header > 0000 : f9a1 8580 0001 032a 0000 0000 > > Question Section - QNAME (2.70.93.199.in-addr.arpa) > 000c : 0132 0237 3002 3933 0331 3939 0769 6e2d 6164 6472 0461 7270 6100 > > Question Section - QTYPE (PTR) > 0026 : 000c > > Question Section - QCLASS (IN) > 0028 : 0001 > > Answer Section - NAME (pointer to 2.70.93.199.in-addr.arpa) > 002a : c00c > > Answer Section - TYPE (PTR) > 002c : 000c > Answer Section - CLASS (IN) > 002e : 0001 > Answer Section - TTL (3600) > 0030 : 0000 0e10 > > Answer Section - RDLENGTH (2) > 0034 : 0002 > > Answer Section - RDATA (PTRDNAME - pointer to itself) > 0036 : c036 >> Another odd thing is that the connection ends with a TCP reset; the >> last few segments are really weird. Instead of the >FIN, <FIN/ACK, >ACK, >> it's >FIN, <FIN/ACK, >ACK, <ACK, >ACK, <RST. This could be what's >> causing the truncation, since a RST flushes any queued data. > With Net::DNS I got >FIN, <ACK, <FIN/ACK, >ACK (no RST). > -- > Michael Fuhr > http://www.fuhr.org/~mfuhr/ > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-bugs" in the body of the message -- -- +------------------------------------------------------------+ . | John Saunders - mailto:john@nlc.net.au (EMail) | ,--_|\ | - http://www.nlc.net.au/ (WWW) | / Oz \ | - 02-9489-4932 or 04-1822-3814 (Phone) | \_,--\_/ | NORTHLINK COMMUNICATIONS P/L - Supplying a professional, | v | and above all friendly, internet connection service. | +------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990303015115.18731.qmail>