Re: postgresql-server exiting abnormally after an OS upgrade

On 2015-02-16 15:55, Tom Lane wrote:
> Hugo Osvaldo Barrera <hugo(at)barrera(dot)io> writes:
> > On 2015-02-13 15:29, Heikki Linnakangas wrote:
> >> Can you get a core dump and a stack trace from it?
>
> > It certainly took me a bit, but, with some help, I managed to get one:
>
> > (gdb) bt
> > #0 0x0000110a2815b92a in kill () at <stdin>:2
> > #1 0x0000110a28195119 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
> > #2 0x0000110a2816a238 in memcpy (dst0=0xfb8d4, src0=0x6, length=0) at /usr/src/lib/libc/string/memcpy.c:65
> > #3 0x000011080cf8d1b1 in check_ip (raddr=0x110a899f7918, addr=0x110a899f9058, mask=0x110a899f9158) at hba.c:704
> > #4 0x000011080cf90a04 in check_hba (port=0x110a899f7800) at hba.c:1718
>
> Huh. You didn't say whether this is 9.3 or 9.4, but it doesn't matter
> because that code is the same in both; the crash is happening here:
>

It's 9.4, the issue appeared after an OS upgrade which was accompanied by an
upgrade to 9.3 I *did* try to downgrade back to 9.3 at that point, but got the
same issue.

> static bool
> check_ip(SockAddr *raddr, struct sockaddr * addr, struct sockaddr * mask)
> {
> ...
> /*
> * If we're connected on IPv6 but the file specifies an IPv4 address
> * to match against, promote the latter to an IPv6 address before
> * trying to match the client's address.
> */
> struct sockaddr_storage addrcopy,
> maskcopy;
>
> memcpy(&addrcopy, &addr, sizeof(addrcopy));
> ---> memcpy(&maskcopy, &mask, sizeof(maskcopy));
>
> Looking at this, the code seems wrong on its face: the memcpy sources
> should be "addr" and "mask", not "&addr" and "&mask". Apparently, no one
> has ever used or tested this case since it was put in :-(. I find that
> a bit astonishing given the steady creep of IPv6 support, but it's hard
> to see how the code could possibly work correctly as-is.
>
> Probably the reason why this was triggered by an OS upgrade is that your
> system is now choosing to make the DB connection over IPv6 not IPv4.
> Or maybe it was doing that right along but you now have a memcpy that is
> doing more checking of its arguments than before (this is evidently an
> argument sanity check and not a straight SIGSEGV).
>

My host has been configured to use IPv6 by default for some time now, but it
*is* possible that there has been some OS-level change during this upgrade that
affected this in some way.

> Anyway you could work around it for now by being sure to list IPv6
> equivalent addresses before IPv4 addresses in your pg_hba.conf.
> We'll fix it properly in the next releases.
>

Do you mean IPv6 *before* IPv4? Wouldn't that add a preference to IPv6?
I currently have the stock out-of-the-box pg_hba:

# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

(I deleted commented out lines for readability).

> regards, tom lane
>

Thanks,

--
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?