PostgreSQL 8.0.0rc2, 7.4.6
Solaris 9, FreeBSD 4.11-PRERELEASE
ECPG's CONNECT TO DEFAULT causes a segmentation fault. This
originally came up in the "Connection without database name" thread
in pgsql-hackers:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00813.php
Example:
#include <stdlib.h>
int main(void)
{
EXEC SQL CONNECT TO DEFAULT;
EXEC SQL DISCONNECT;
return 0;
}
% ./foo
Segmentation fault (core dumped)
% gdb ./foo core
...
(gdb) bt
#0 0xff2344e4 in strlen () from /usr/lib/libc.so.1
#1 0xff254224 in strdup () from /usr/lib/libc.so.1
#2 0xff368ecc in ECPGconnect (lineno=0, c=-1, name=0x0, user=0x0, passwd=0x0,
connection_name=0x107b8 "DEFAULT", autocommit=-14465948) at connect.c:245
#3 0x00010704 in main () at foo.pgc:4
ecpg generates the following for CONNECT TO DEFAULT:
{ ECPGconnect(__LINE__, 0, NULL,NULL,NULL,"DEFAULT", 0); }
The problem appears to be when assigning dbname at the beginning
of ECPGconnect():
char *dbname = strdup(name),
"name" is the third argument to ECPGconnect() so it's NULL in this
case. Many systems' standard libraries segfault when strdup() is
called with a NULL pointer.
Several other places in ECPGconnect() look like they'll have a
problem if dbname is NULL. Lines 275-279, for example:
if (dbname == NULL && connection_name == NULL)
connection_name = "DEFAULT";
/* get the detail information out of dbname */
if (strchr(dbname, '@') != NULL)
The first "if" considers the possibility that dbname is NULL, but
then the second "if" and subsequent code passes that possibly-NULL
pointer to various functions that will probably segfault if dbname
is indeed NULL.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
