this is PR lib/25892.  Not sure what the problem is, but it appears
to actually be occuring within the libc resolver.

you can likely work around by rolling your libc back to ~12.117 or
using addresses instead of names in your ntpd.confg.

Mon, Jun 28, 2004 at 07:18:32PM -0400, Chris Ross:
> Chris Ross wrote:
> >  I'm building the current ntp (et al) in usr.sbin/ntp.  I built
> >it last week, and when I noticed [while trying to run it] today
> >that it failed, I rebuilt from today's sources (for the binaries,
> >I guess I should rebuild the kernel next, but I don't remember
> >seeing any changes that I think would effect this)
> >
> >  ntpd will SEGV shortly after starting.  Both the older and current
> >binaries fail in the same way.  I have "ca.pool.ntp.org" and
> >two "us.pool.ntp.org" "server" lines in my ntp.conf, which is
> >the default after changing commented lines in and out.
> 
>   I've done a little more "printf-style debugging" of this problem.
> The problem appears to be in ntpd/ntp_config.c.  In the CONFIG_SERVER
> case of the main loop in the getconfig() function, it calls memset()
> on the address of a local (stack) structure.  It's declared:
> 
>         struct sockaddr_storage peeraddr;
> 
>   And memset is called:
> 
>         istart = 1;
>         memset((char *)&peeraddr, 0, sizeof(peeraddr));
> 
>   Immediately before those two lines (listed right above, here),
> I put:
> 
>         if (debug)
>              printf("Initializing, NULL'ing 0x%p\n", &peeraddr);
> 
>   And, when it runs, right before it SEGV's, I see:
> 
> Initializing, NULL'ing 0x0xffffffffffffc8d0
> zsh: segmentation fault (core dumped)  ./ntpd -d
> 
>   So, is this a compiler/toolchain bug?  Looks like it to me.
> Should I submit a pr on it?  I guess I'd have to make a
> better test case.  But, this sort of thing can't *always*
> be broken like this, or many more programs would be busted,
> no?
> 
>   Thanks.  Any input welcomed...
> 
>                             - Chris