Re: postgresql-server exiting abnormally after an OS upgrade

Hugo Osvaldo Barrera <hugo@barrera.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:

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).

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.

            regards, tom lane