Re: postgresql-server exiting abnormally after an OS upgrade

On 2015-02-16 15:55, Tom Lane wrote:
> 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?
>=20
> > It certainly took me a bit, but, with some help, I managed to get one:
>=20
> >   (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=3D0xfb8d4, src0=3D0x6, length=
=3D0) at /usr/src/lib/libc/string/memcpy.c:65
> >   #3  0x000011080cf8d1b1 in check_ip (raddr=3D0x110a899f7918, addr=3D0x=
110a899f9058, mask=3D0x110a899f9158) at hba.c:704
> >   #4  0x000011080cf90a04 in check_hba (port=3D0x110a899f7800) at hba.c:=
1718
>=20
> 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:
>=20

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 addr=
ess
>          * to match against, promote the latter to an IPv6 address before
>          * trying to match the client's address.
>          */
>         struct sockaddr_storage addrcopy,
>                     maskcopy;
>=20
>         memcpy(&addrcopy, &addr, sizeof(addrcopy));
> --->    memcpy(&maskcopy, &mask, sizeof(maskcopy));
>=20
> 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.
>=20
> 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).
>=20

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.
>=20

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
>=20

Thanks,

--=20
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?