Re: Bug Report with Postgres 7.4 on AIX 5.3

Vincent,

Thanks for this, I'll run this by our SAs. Should
be funny to watch their reaction.

Meanwhile, I've requested that we file a bug w/IBM
as well.

Thanks again for sharing your information!

-- Ross Mohan

-----Original Message-----
From: Vincent Vanwynsberghe [mailto:vvanwynsberghe(at)ccncsi(dot)net]
Sent: Thu 5/19/2005 8:49 AM
To: pgsql-ports(at)postgresql(dot)org; pgsql-bugs(at)postgresql(dot)org
Cc: Mohan, Ross
Subject: RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
Hi,

We opened a call to IBM also, but until now we didn't receive anything (see
the attached mail).
In order to take into account the RFC 3943, we find a way to fixed the
problem by modifying the file socket.h :

#define _SS_MAXSIZE 128 /* Implementation specific max size */

SHOULD BE REPLACED BY

#define _SS_MAXSIZE (sizeof(struct sockaddr_un)) /* Implementation
specific max size */

With this modification, Postgres 7.4 run on AIX5.3.
This is really an AIX problem.

An other's proposal done by Bull (our provider of the AIX system) is the
following :
Reduce the size of the field sun_path in the structure sockaddr_un (un.h)
and not increase the size of the structure sockaddr_storage.

char sun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to support
long user names */

SHOULD BE REPLACED BY

char sun_path[104]; /* changed from 104 to PATH_MAX to support long
user names */

With this modification, Postgres 7.4 run also on AIX5.3.

Both modification can have an impact on the AIX5.3 OS and IBM should be
confirm if a fixed is needed for that problem ?

Kind Regards,
Vincent Vanwynsberghe

> -----Original Message-----
> From: Mohan, Ross [mailto:RMohan(at)arbinet(dot)com]
> Sent: jeudi 19 mai 2005 2:23
> To: vvanwynsberghe(at)ccncsi(dot)net
> Subject: RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Vincent,
>
> 1) I am having the exact same problem: I cannot even do a
> CREATEDB in 8.0.2 on AIX5.3
>
> 2) You sent your mail to the PG lists, but not to IBM, possibly?
>
> 3) If you think it will help, I can call support as well.
>
>
>
> If you get ANY word on this, whether a fix, a tweak, or a
> workaround, please Please PLEASE
> post to the list rapidly.
>
> We're dead in the water on this and the IT environment around
> here is such that if I can't
> get PG working on AIX, it'll be marked for death. And I really
> wanted to start
> using PG around here.
>
> Thanks!!!!!
>
>
> -- Ross Mohan
>
>
>
> -----Original Message-----
> From: pgsql-ports-owner(at)postgresql(dot)org
> [mailto:pgsql-ports-owner(at)postgresql(dot)org] On Behalf Of Vincent
> Vanwynsberghe
> Sent: Tuesday, May 10, 2005 4:08 AM
> To: pgsql-ports(at)postgresql(dot)org; pgsql-bugs(at)postgresql(dot)org
> Subject: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Dear Support,
>
> We try to install Postgres 7.4 on AIX 5.3 (IBM,9111-520).
> The compilation is good and we are able to start the postmaster.
> When we try to start the psql we got the following error :
> FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
>
> We run the psql under the AIX debugger dbx and our conclusions
> are the following :
>
> In the file fe-connect.c we try to copy a area of 1025 in the
> conn->raddr.addr area but the size of that area is only 144.
> The result is a corruption of the pg_conn structure
>
> +1175 /* Remember
> current address
> for possible error msg */
> +1176 memcpy(&conn->raddr.addr,
> addr_cur->ai_addr,
> +1177
> addr_cur->ai_addrlen);
>
>
> The addr_cur->ai_addrlen is set with the sizeof(struct
> sockaddr_un) in the file ip.c.
>
> In the file libpq-int.h the structure pg_conn contains 2 fields SockAddr
> * PGconn stores all the state data associated with a single connection
> * to a backend.
> */
> struct pg_conn
> {
> ...
> SockAddr laddr; /* Local address */
> SockAddr raddr;
> ...
> }
>
> The structure SockAddr is defined in the file pqcomm.h
>
> typedef struct
> {
> struct sockaddr_storage addr;
> ACCEPT_TYPE_ARG3 salen;
> } SockAddr;
>
>
> On Our AIX 5.3 the sockaddr_un is defined in the file
> /usr/include/sys/un.h
>
> #if defined(COMPAT_43) && !defined(_KERNEL)
> struct sockaddr_un {
> ushort_t sun_family; /* AF_UNIX */
> char sun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
> support long user names */
> };
> #else
> struct sockaddr_un {
> uchar_t sun_len; /* sockaddr len including null */
> sa_family_t sun_family; /* AF_UNIX */
> char sun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
> support long user names */
> };
> #endif /* COMPAT_43 && !_KERNEL */
>
> PATH_MAX is defined in the file /usr/include/sys/limits.h
>
> #if _POSIX_C_SOURCE >= 200112L && !(defined _ALL_SOURCE) ||
> defined(_PATHMAX_HAS_NULL)
> #define PATH_MAX 1024 /* max number of bytes in a
> pathname.
> includes a terminating
> null */ #else
> #define PATH_MAX 1023
> #endif
>
> In our platform the sizeof of struct sockaddr_un is 1025 and the
> sizeof of SockAddr is 144. In conclusion the instructions done in
> the function PQconnectPoll cause a memory overflow !!!
>
> +1175 /* Remember current address
> for possible error msg */
> +1176 memcpy(&conn->raddr.addr,
> addr_cur->ai_addr,
> +1177
> addr_cur->ai_addrlen);
>
> Are you aware about this problem ?
> Could you give us a way to solve the problem ?
>
> Kind Regards,
> Vincent Vanwynsberghe
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've begun the escalation process for this issue with our IBM account
rep. I'll post the APAR number for this issue to the list when I have one.

- --
Andrew Hammond 416-673-4138 ahammond(at)ca(dot)afilias(dot)info
Database Administrator, Afilias Canada Corp.
CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A

Mohan, Ross wrote:
> Vincent,
>
> Thanks for this, I'll run this by our SAs. Should
> be funny to watch their reaction.
>
> Meanwhile, I've requested that we file a bug w/IBM
> as well.
>
> Thanks again for sharing your information!
>
> -- Ross Mohan
>
>
> -----Original Message-----
> From: Vincent Vanwynsberghe [mailto:vvanwynsberghe(at)ccncsi(dot)net]
> Sent: Thu 5/19/2005 8:49 AM
> To: pgsql-ports(at)postgresql(dot)org; pgsql-bugs(at)postgresql(dot)org
> Cc: Mohan, Ross
> Subject: RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
> Hi,
>
> We opened a call to IBM also, but until now we didn't receive anything (see
> the attached mail).
> In order to take into account the RFC 3943, we find a way to fixed the
> problem by modifying the file socket.h :
>
> #define _SS_MAXSIZE 128 /* Implementation specific max size */
>
> SHOULD BE REPLACED BY
>
> #define _SS_MAXSIZE (sizeof(struct sockaddr_un)) /* Implementation
> specific max size */
>
> With this modification, Postgres 7.4 run on AIX5.3.
> This is really an AIX problem.
>
> An other's proposal done by Bull (our provider of the AIX system) is the
> following :
> Reduce the size of the field sun_path in the structure sockaddr_un (un.h)
> and not increase the size of the structure sockaddr_storage.
>
> char sun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to support
> long user names */
>
> SHOULD BE REPLACED BY
>
> char sun_path[104]; /* changed from 104 to PATH_MAX to support long
> user names */
>
> With this modification, Postgres 7.4 run also on AIX5.3.
>
> Both modification can have an impact on the AIX5.3 OS and IBM should be
> confirm if a fixed is needed for that problem ?
>
> Kind Regards,
> Vincent Vanwynsberghe
>
>
>>-----Original Message-----
>>From: Mohan, Ross [mailto:RMohan(at)arbinet(dot)com]
>>Sent: jeudi 19 mai 2005 2:23
>>To: vvanwynsberghe(at)ccncsi(dot)net
>>Subject: RE: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>>
>>
>>Vincent,
>>
>>1) I am having the exact same problem: I cannot even do a
>>CREATEDB in 8.0.2 on AIX5.3
>>
>>2) You sent your mail to the PG lists, but not to IBM, possibly?
>>
>>3) If you think it will help, I can call support as well.
>>
>>
>>
>>If you get ANY word on this, whether a fix, a tweak, or a
>>workaround, please Please PLEASE
>>post to the list rapidly.
>>
>>We're dead in the water on this and the IT environment around
>>here is such that if I can't
>>get PG working on AIX, it'll be marked for death. And I really
>>wanted to start
>>using PG around here.
>>
>>Thanks!!!!!
>>
>>
>>-- Ross Mohan
>>
>>
>>
>>-----Original Message-----
>>From: pgsql-ports-owner(at)postgresql(dot)org
>>[mailto:pgsql-ports-owner(at)postgresql(dot)org] On Behalf Of Vincent
>>Vanwynsberghe
>>Sent: Tuesday, May 10, 2005 4:08 AM
>>To: pgsql-ports(at)postgresql(dot)org; pgsql-bugs(at)postgresql(dot)org
>>Subject: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3
>>
>>
>>Dear Support,
>>
>>We try to install Postgres 7.4 on AIX 5.3 (IBM,9111-520).
>>The compilation is good and we are able to start the postmaster.
>>When we try to start the psql we got the following error :
>>FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
>>
>>We run the psql under the AIX debugger dbx and our conclusions
>>are the following :
>>
>>In the file fe-connect.c we try to copy a area of 1025 in the
>>conn->raddr.addr area but the size of that area is only 144.
>>The result is a corruption of the pg_conn structure
>>
>> +1175 /* Remember
>>current address
>>for possible error msg */
>> +1176 memcpy(&conn->raddr.addr,
>>addr_cur->ai_addr,
>> +1177
>>addr_cur->ai_addrlen);
>>
>>
>>The addr_cur->ai_addrlen is set with the sizeof(struct
>>sockaddr_un) in the file ip.c.
>>
>>In the file libpq-int.h the structure pg_conn contains 2 fields SockAddr
>> * PGconn stores all the state data associated with a single connection
>> * to a backend.
>> */
>>struct pg_conn
>>{
>>...
>> SockAddr laddr; /* Local address */
>> SockAddr raddr;
>>...
>>}
>>
>>The structure SockAddr is defined in the file pqcomm.h
>>
>>typedef struct
>>{
>> struct sockaddr_storage addr;
>> ACCEPT_TYPE_ARG3 salen;
>>} SockAddr;
>>
>>
>>On Our AIX 5.3 the sockaddr_un is defined in the file
>>/usr/include/sys/un.h
>>
>>#if defined(COMPAT_43) && !defined(_KERNEL)
>>struct sockaddr_un {
>> ushort_t sun_family; /* AF_UNIX */
>> char sun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
>>support long user names */
>>};
>>#else
>>struct sockaddr_un {
>> uchar_t sun_len; /* sockaddr len including null */
>> sa_family_t sun_family; /* AF_UNIX */
>> char sun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
>>support long user names */
>>};
>>#endif /* COMPAT_43 && !_KERNEL */
>>
>>PATH_MAX is defined in the file /usr/include/sys/limits.h
>>
>>#if _POSIX_C_SOURCE >= 200112L && !(defined _ALL_SOURCE) ||
>>defined(_PATHMAX_HAS_NULL)
>>#define PATH_MAX 1024 /* max number of bytes in a
>>pathname.
>> includes a terminating
>>null */ #else
>>#define PATH_MAX 1023
>>#endif
>>
>>In our platform the sizeof of struct sockaddr_un is 1025 and the
>>sizeof of SockAddr is 144. In conclusion the instructions done in
>>the function PQconnectPoll cause a memory overflow !!!
>>
>>+1175 /* Remember current address
>>for possible error msg */
>>+1176 memcpy(&conn->raddr.addr,
>>addr_cur->ai_addr,
>>+1177
>>addr_cur->ai_addrlen);
>>
>>Are you aware about this problem ?
>>Could you give us a way to solve the problem ?
>>
>>Kind Regards,
>>Vincent Vanwynsberghe
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 7: don't forget to increase your free space map settings
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCk12ugfzn5SevSpoRAqpNAJ9OFKLh1NUR54GtiPYdm+mnWxUJpACfWd19
SQo+oU/CN/b4fi13hGqHovg=
=rg8x
-----END PGP SIGNATURE-----