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...2/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 majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Tue, Dec 28, 2004 at 11:15:52PM -0700, Michael Fuhr wrote:

This is exactly what I did fix with the work mentioned in the hackers
thread. It should work nicely with CVS HEAD. Could you please try this?

BTW Tom, I just found that my problem with PGDATABASE was a local one.
It surely works, so the oracle style syntax will remain. That is you can also
write EXEC SQL CONNECT <username> to connect to the default database using the
given username.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes (AT) jabber (DOT) org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Wed, Dec 29, 2004 at 10:32:21AM +0100, Michael Meskes wrote:
Try what? I don't see a patch, link, or suggested fix in the
thread -- just your original message and the two followups by
Tom Lane and me. Or was the fix discussed in a different thread?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Zitat von Michael Fuhr <mike (AT) fuhr (DOT) org>:

Sorry, something didn't work on my side as I thought they would. I just
noticed that I did not commit my changes. They are now. So using the cvs version
or the next release candidate should fix the problem. I'm sorry, but I do not
have a patch against 7.4 at the moment.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes (AT) jabber (DOT) org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org