Thread: BUG #2014: createdb and other client binaries core dumps

BUG #2014: createdb and other client binaries core dumps

From
"Shaick"
Date:
The following bug has been logged online:

Bug reference:      2014
Logged by:          Shaick
Email address:      shaick.pop@gmail.com
PostgreSQL version: 8.0.4
Operating system:   HPUX
Description:        createdb and other client binaries core dumps
Details:

We try to build postgreSQL 8.0.4 on HPUX 11.11 and in 64 bit client binaries
core dumps.
But in postgreSQL 8.0.3 we didn't face any issue.

Details are given below.
While starting postmaster we received following warnings,
$ ./postmaster -h 127.0.0.1 -i -D /var/opt/iexpress/postgresql_64
LOG:  could not bind IPv6 socket: Invalid argument
HINT:  Is another postmaster already running on port 5432? If not, wait a
few seconds and retry.
LOG:  could not bind IPv4 socket: Invalid argument
HINT:  Is another postmaster already running on port 5432? If not, wait a
few seconds and retry.
WARNING:  could not create listen socket for "*"
LOG:  could not bind socket for statistics collector: Invalid argument
LOG:  disabling statistics collector for lack of working socket
LOG:  database system was shut down at 2005-11-02 10:45:23 IST
LOG:  checkpoint record is at 0/261380
LOG:  redo record is at 0/261380; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 242; next OID: 25046
LOG:  database system is ready


tusc output of createdb is given below,
$ tusc  ./createdb test1;
execve("./createdb", 0x7f7f0810, 0x7f7f081c)
........................................................... = 0 [64-bit]
getuid()
............................................................................
................... = 118 (118)
g
<----snip---->
stat("/home/postgres/.pgpass", 0x800003ffff7f1590)
..................................................... ERR#2 ENOENT
socket2(1, 1, 0)
............................................................................
........... = 4
fcntl(4, F_SETFL, 65536)
............................................................................
... = 0
fcntl(4, F_SETFD, 1)
............................................................................
....... = 0
connect(4, 0x800000010000a278, 94)
..................................................................... = 0
  Received signal 10, SIGBUS, in user mode, [SIG_DFL], partial siginfo
    Siginfo: si_code: I_NONEXIST, faulting address: 0xff7f0f64 (32-bit),
si_errno: 0
    PC: 0xc00000000002a33b, instruction: 0x507f0000
exit(10) [implicit]
............................................................................
........ WIFSIGNALED(SIGBUS)

Thanks,
Shaick

Re: BUG #2014: createdb and other client binaries core dumps

From
Tom Lane
Date:
"Shaick" <shaick.pop@gmail.com> writes:
> We try to build postgreSQL 8.0.4 on HPUX 11.11 and in 64 bit client binaries
> core dumps.
> But in postgreSQL 8.0.3 we didn't face any issue.

[ diffs tarballs... ]  Hmm, there is not very much at all changed in our
client-side code between 8.0.3 and 8.0.4.  Are you sure nothing else
changed in your environment?  What compiler and what configure options
did you use?

Can you provide a debugger stack trace from the core dump?

            regards, tom lane

Re: BUG #2014: createdb and other client binaries core dumps

From
"Shaick"
Date:
Hello Tom,

The problem is socklen_t is accidentally typedef to int instead of size_t.
Now the issue is
resolved.

Thanks,
Shaick.
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Shaick" <shaick.pop@gmail.com>
Cc: <pgsql-bugs@postgresql.org>
Sent: Wednesday, November 02, 2005 10:26 PM
Subject: Re: [BUGS] BUG #2014: createdb and other client binaries core dumps


> "Shaick" <shaick.pop@gmail.com> writes:
> > We try to build postgreSQL 8.0.4 on HPUX 11.11 and in 64 bit client
binaries
> > core dumps.
> > But in postgreSQL 8.0.3 we didn't face any issue.
>
> [ diffs tarballs... ]  Hmm, there is not very much at all changed in our
> client-side code between 8.0.3 and 8.0.4.  Are you sure nothing else
> changed in your environment?  What compiler and what configure options
> did you use?
>
> Can you provide a debugger stack trace from the core dump?
>
> regards, tom lane