From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Stats Collector Won't Start |
Date: | 2006-10-19 16:01:35 |
Message-ID: | 15491.1161273695@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Chris Browne <cbbrowne(at)acm(dot)org> writes:
> tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
>> Chris Browne <cbbrowne(at)acm(dot)org> writes:
>>> (gdb) print addr->ai_addr->sa_data
>>> $18 = "\000\001\177\000\000\001\000\000\000\000\000\000\000"
>>
>> Hmm, that looks a bit odd --- what's the full declaration of structs
>> sockaddr and sockaddr_in on that machine?
> struct sockaddr {
> uchar_t sa_len; /* total length */
> sa_family_t sa_family; /* address family */
> char sa_data[14]; /* actually longer; address value */
> };
> struct sockaddr_in {
> uchar_t sin_len;
> sa_family_t sin_family;
> in_port_t sin_port;
> struct in_addr sin_addr;
> uchar_t sin_zero[8];
> };
So you've got sin_port = 1, which explains the permission-denied
message. Next question is why getaddrinfo is setting it that way
rather than to zero. Is it possible that getaddrinfo is failing
to initialize the field at all, and we're just getting bit by
random pre-existing memory contents?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sandeep Kumar Jakkaraju | 2006-10-19 16:01:40 | Re: PostGIS |
Previous Message | Chris Browne | 2006-10-19 16:00:06 | Re: Stats Collector Won't Start |