FAQ
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

Search Discussions

  • Tom Lane at May 10, 2005 at 4:46 pm

    Vincent Vanwynsberghe writes:
    In our platform the sizeof of struct sockaddr_un is 1025 and the sizeof of
    SockAddr is 144.
    Doesn't AIX provide struct sockaddr_storage? That struct has to be at
    least as large as any of the other platform-specific sockaddr structs.

    regards, tom lane
  • Vincent Vanwynsberghe at May 11, 2005 at 1:05 pm
    The AIX 5.3 provide the structure sockaddr_storage :

    struct sockaddr_storage {
    ushort_t __ss_family; /* address family */
    char __ss_pad1[_SS_PAD1SIZE]; /* pad up to alignment
    field */
    #if defined(__64BIT__) || (defined(_ALL_SOURCE) && defined(_LONG_LONG))
    int64_t __ss_align; /* field to force desired structure
    */
    /* storage alignment */
    #else
    int __ss_align[2];
    #endif
    char __ss_pad2[_SS_PAD2SIZE];
    /* pad to achieve desired size */
    };


    In Postgres the structure SockAddr is the following :
    typedef struct
    {
    struct sockaddr_storage addr;
    ACCEPT_TYPE_ARG3 salen;
    } SockAddr

    In Postgress this structure sockaddr_storage is filled with the structure
    sockaddr_un but the size of sockaddr_storage
    is less then the size of sockaddr_un and cause a memory overflow !

    Do you have any idea how to find a workaround ?

    Vincent Vanwynsberghe
    -----Original Message-----
    From: Tom Lane
    Sent: mardi 10 mai 2005 18:46
    To: vvanwynsberghe@ccncsi.net
    Cc: pgsql-ports@postgresql.org; pgsql-bugs@postgresql.org
    Subject: Re: [BUGS] Bug Report with Postgres 7.4 on AIX 5.3


    Vincent Vanwynsberghe <vvanwynsberghe@ccncsi.net> writes:
    In our platform the sizeof of struct sockaddr_un is 1025 and
    the sizeof of
    SockAddr is 144.
    Doesn't AIX provide struct sockaddr_storage? That struct has to be at
    least as large as any of the other platform-specific sockaddr structs.

    regards, tom lane
  • Tom Lane at May 11, 2005 at 4:02 pm

    Vincent Vanwynsberghe writes:
    The AIX 5.3 provide the structure sockaddr_storage :
    ...
    In Postgress this structure sockaddr_storage is filled with the structure
    sockaddr_un but the size of sockaddr_storage
    is less then the size of sockaddr_un and cause a memory overflow !
    Do you have any idea how to find a workaround ?
    Report this bug to IBM: the AIX headers are defining the structs wrong.
    You can quote RFC 3493 - Basic Socket Interface Extensions for IPv6
    section 3.10:

    One simple addition to the sockets API that can help application
    writers is the "struct sockaddr_storage". This data structure can
    simplify writing code that is portable across multiple address
    families and platforms. This data structure is designed with the
    following goals.

    - Large enough to accommodate all supported protocol-specific address
    structures.


    regards, tom lane
  • Mohan, Ross at May 19, 2005 at 12:22 am
    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@postgresql.org On Behalf Of Vincent Vanwynsberghe
    Sent: Tuesday, May 10, 2005 4:08 AM
    To: pgsql-ports@postgresql.org; pgsql-bugs@postgresql.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
  • Mohan, Ross at May 19, 2005 at 1:46 pm
    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
    Sent: Thu 5/19/2005 8:49 AM
    To: pgsql-ports@postgresql.org; pgsql-bugs@postgresql.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
    Sent: jeudi 19 mai 2005 2:23
    To: vvanwynsberghe@ccncsi.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@postgresql.org
    On Behalf Of Vincent
    Vanwynsberghe
    Sent: Tuesday, May 10, 2005 4:08 AM
    To: pgsql-ports@postgresql.org; pgsql-bugs@postgresql.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
  • Andrew Hammond at May 24, 2005 at 5:00 pm
    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@ca.afilias.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
    Sent: Thu 5/19/2005 8:49 AM
    To: pgsql-ports@postgresql.org; pgsql-bugs@postgresql.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
    Sent: jeudi 19 mai 2005 2:23
    To: vvanwynsberghe@ccncsi.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@postgresql.org
    On Behalf Of Vincent
    Vanwynsberghe
    Sent: Tuesday, May 10, 2005 4:08 AM
    To: pgsql-ports@postgresql.org; pgsql-bugs@postgresql.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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedMay 10, '05 at 8:08a
activeMay 24, '05 at 5:00p
posts7
users4
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase