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/ ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
