Crash in ns_lookup restarting Gnus

[Rohan Hart]

In GNU Emacs 21.1.2 (mips-sgi-irix6.5, X toolkit, Xaw3d scroll bars)
 of 2002-01-10 on metro
configured using `configure  --prefix=/usr/shared-apps/ 
--bindir=/usr/shared-apps/bin/mips --with-extra-lib=/usr/shared-apps/lib 
--with-extra-inc=/usr/shared-apps/include'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

When restarting Gnus, ie. M-x gnus <ret>, having previously quited
Gnus but not Emacs, Emacs hits a segmentation fault:

Process 210611 (emacs-21.1) stopped on signal SIGSEGV: Segmentation violation
    (handled) at [__ns_cache_open:36 +0x10,0xfaab64c]
         Source (of /xlv47/6.5.5m/work/irix/lib/libc/libc_n32_M4/ns/ns_cache.c)
             not available for Process 210611

The stack trace (under dbx which doesn't understand the gcc portion of
the stack, but then gdb doesn't understand the Irix cc portion of the stack):

   0 __ns_cache_open(0x7fff0634, 0xfb2ebc8, 0x2f, 0xfb2ebcf, 0x65736963, 
0x7fff062f, 0x1, 0xfb2ebd1) 
["/xlv47/6.5.5m/work/irix/lib/libc/libc_n32_M4/ns/ns_cache.c":36, 0xfaab64c]
   1 _ns_lookup(0x7fff0634, 0x0, 0xfb2ebc8, 0x7fff0f90, 0x0, 0x0, 0x0, 
0xfb2ebd1) ["/xlv47/6.5.5m/work/irix/lib/libc/libc_n32_M4/ns/ns_lookup.c":60, 
0xfaac3a8]
   2 _getservbyname_r(0x10c4f6b8, 0x1023a828, 0x2f, 0x10bdc000, 0x65736963, 
0x7fff062f, 0x1, 0xfb2ebd1) 
["/xlv47/6.5.5m/work/irix/lib/libc/libc_n32_M4/ns/ns_services.c":319, 0xfb0ccac]
   3 _getservbyname(0x10c4f6b8, 0x0, 0x2f, 0xfb2ebcf, 0x65736963, 0x7fff062f, 
0x1, 0xfb2ebd1) 
["/xlv47/6.5.5m/work/irix/lib/libc/libc_n32_M4/ns/ns_services.c":373, 0xfb0cf5c]
   4 <Unknown>() [< unknown >, 0x101d9b1c]

The first parameter to getservbyname, which I think is the server
name, is "nntp" (which isn't a valid server name here), while the
second, protocol, is "tcp".

Rohan