Christos Zoulas wrote:
> I just fixed it. It was ntpd's fault for reducing the stack to only 80K
> which is not enough for a 64 bit machine and the new resolver.

   Really?  Hmm.  I just found a failure in libc's resolv code that
looks like an alignment problem.  I was tracing the failure of
ntpd with a debugging libc, and found that in res_nameinquiry(),
which in my trace was being passed ("us.pool.ntp.org", 28, 1, 0x3d6000,
0x3e60000), it was SEGV'ing in the first line, declaring:

   const u_char *cp = buf + HFIXEDSZ;

   Now, since buf (0x3d6000) is a u_char*, and HFIXEDSZ is 12, I
thought this looked like an unaligned memory access problem.
Not that it *should* be a problem since we're only accessing
it as a char, but...

   But anyway.  I guess if it is trying to allocate this on the
stack, and it's out of stack, it would also have this problem.
Shoo.  I'm glad I got email from you then, or I'd be tracing
this as an alignment problem.  :-)

   Thanks!

                           - Chris