PQdb() fails with coredump when PQconnectDB() passed invalid parameter.
version 7.4.5
using postgresql-7.4.5/src/test/examples/testlibpq as follows
"testlibpq hostname=shouldHaveUsedHostNotHostname"
fails with coredump
SunOS pluto 5.9 Generic_117171-07 sun4u sparc SUNW,Ultra-5_10
On Wed, Sep 29, 2004 at 05:59:37PM +0100, Trevor Inns wrote:
version 7.4.5
using postgresql-7.4.5/src/test/examples/testlibpq as follows
"testlibpq hostname=shouldHaveUsedHostNotHostname"
fails with coredump
SunOS pluto 5.9 Generic_117171-07 sun4u sparc SUNW,Ultra-5_10
Confirmed on Solaris 9 with PostgreSQL 8.0.0beta3 (CVS). Here's
a stack trace:
#0 0xff1344e4 in strlen () from /usr/lib/libc.so.1
#1 0xff186bec in _doprnt () from /usr/lib/libc.so.1
#2 0xff18861c in fprintf () from /usr/lib/libc.so.1
#3 0x00010a08 in main (argc=135304, argv=0x10cd8) at testlibpq.c:44
Here's line 44:
fprintf(stderr, "Connection to database '%s' failed.\n", PQdb(conn));
PQdb() is returning NULL, which causes fprintf() to dump core.
On FreeBSD 4.10-STABLE, fprintf() handles NULL:
Connection to database '(null)' failed.
invalid connection option "hostname"
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
Michael Fuhr <mike@fuhr.org> writes:
PQdb() is returning NULL, which causes fprintf() to dump core.
It is actually documented that a failed connection might return NULL for
this, so the example code is wrong. I've corrected the examples to not
assume PQdb can be used on a failed connection.
pg_dump was doing it wrong too :-(
regards, tom lane