Libpq free bug? (Was: [ODBC] IIS Postgres ASP ADO - Problem)

Started by Dave Pageover 20 years ago5 messagesbugs
Jump to latest
#1Dave Page
dpage@pgadmin.org

Forwarded to -bugs in case it gets missed.

This looks like it might be an issue to me, though I may well have
overlooked something in my brief look at the code.

Regards, Dave

-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marko Ristola
Sent: 01 August 2005 18:15
To: Joel Fradkin
Cc: 'James Dornan'; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] IIS Postgres ASP ADO - Problem

I found a crashing problem during CONNECT into a database.

Here is the problem description:

Used Environment:
libpq-API under PostgreSQL 8.0.3
CVS HEAD of psqlodbc

libpq does have a problem with freeing memory, that has not
been alloced
with malloc()!

Here is the problem (I don't know, wether the PostgreSQL CVS
HEAD has a
fix for this):

postgresql-8.0.3/src/interfaces/libpq/fe-connect.c, function
conninfo_parse():

/* Make a working copy of PQconninfoOptions */
options = malloc(sizeof(PQconninfoOptions));
...
memcpy(options, PQconninfoOptions,
sizeof(PQconninfoOptions));

Unfortunately PQconninfoOptions[] contains only char*val
style pointers
instead of
char val[32] type character containers.
Because of this, the assumption, that memcpy() is enough to copy the
structure, is not
true anymore. You should NOT copy a static structure this way!

Working code would be something like this:

options = malloc(sizeof(PQconninfoOptions));
memcpy(options, PQconninfoOptions, sizeof(PQconninfoOptions));
for (i=0; PQconninfoOptions[i].val != NULL; i++) {
options[i].val = strdup(PQconninfoOptions[i].val);
... same for all other values
}
NULL termination.

Because of this, isql fails with me at the beginning, maybe because
dmalloc library, that I use for testing, discovered the problem.

Marko Ristola

Joel Fradkin wrote:

James,

The odbc is not working well for me (I can connect but get

intermittent

issues of the IIS server locking up in regards to connectivity).
My understanding is the snapshot version is the best odbc

out at this time.

Also can you connect via pgadmin (IE have the hba and config

files set to

allow external connections)?

My conection is not using dsn, but I did get dsn to work in testing.
My dsnless string is

Session("StringConn") =
"DRIVER={PostgreSQL};DATABASE=wazagua;SERVER=192.168.123.121;

PORT=5432;UID=p

ostgres;PWD=;ReadOnly=0;Protocol=6.4;FakeOidIndex=0;ShowOidCo

lumn=0;RowVersi

oning=0;ShowSystemTables=0;ConnSettings=;Fetch=100;Socket=409

6;UnknownSizes=

0;MaxVarcharSize=254;MaxLongVarcharSize=8190;Debug=0;CommLog=

0;Optimizer=1;K

sqo=1;UseDeclareFetch=0;TextAsLongVarchar=1;UnknownsAsLongVar

char=0;BoolsAsC

har=1;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;LF

Conversion=1;Up

datableCursors=1;DisallowPremature=0;TrueIsMinus1=0;BI=0;Byte

aAsLongVarBinar

Show quoted text

y=0;UseServerSidePrepare=0"

My test using dsn used
Session("StringConn") ="DSN=postgresql;" & _
"UID=postgres;" & _
"PWD=;" & _
"Database=wazuni;"

asp code to use connection is :
dim Arec, Acmd, SQL ,AConn
set Arec = server.CreateObject("ADODB.Recordset")
Set AConn = Server.CreateObject("ADODB.CONNECTION")
set Acmd = server.CreateObject("ADODB.Command")
AConn.ConnectionTimeOut=30
AConn.commandtimeout=30
AConn.Open Session("StringConn")

For .net I use the npgsql .net objects.

Hope this helps you.

Joel Fradkin

-----Original Message-----
From: James Dornan [mailto:james@catch22.com]
Sent: Sunday, July 31, 2005 4:44 PM
To: jfradkin@wazagua.com
Subject: IIS Postgres ASP ADO - Problem

I noticed more than a few post from you about trying to

get Postgres

working with ODBC.
I'm hoping that maybe you would share some of that information. I am
running IIS under
windos 2003 server, and the latest(8.0.3) Postgres server on

the same

machine. I cannot
connect no matter what I do. I have tried everything.

The funny part is that I'm not new to ODBC, or windows.

I've worked

with windows all
the time, but just can't figure this one out. I've tried using a
connection string, a DSN,
reinstalling, IIS, Postgres, ODBC drivers, MDAC, Jet, and so

on. I still

have the same problem.
The odbc drive and it's dependant DDLs are in the path. The

permisions

are wide open
(for testing this specific problem).

Is there any insight you could shed on the dark world of

windows and

ODBC, where feed-
back is rare.

Thanks for any help you can provide.

-- James

---------------------------(end of

broadcast)---------------------------

TIP 2: Don't 'kill -9' the postmaster

---------------------------(end of
broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

#2Marko Ristola
marko.ristola@kolumbus.fi
In reply to: Dave Page (#1)
Re: Libpq free bug? (Was: [ODBC] IIS Postgres ASP ADO - Problem)

Personally I cancelled this bug report:
The code contains a number of malloc() avoidance hacks for speedup, but
it seems to
be correct:

The speed optimizations confused me.

It seems, that only free(options[i].var) will be freed, if "var" is not
NULL.
Also free(options) will be freed. So this seems to work, because
PQconninfoOptions[i].val is NULL for every valid i.

Memory allocation debugger does not find any bugs here.
I was able to test that with my test.cpp.

Even though I could not find a bug in the case that Dave forwarded,
there is still a CONNECT problem that I can reproduce.

My CONNECT problem seems to be related with isql and self compiled
libdmalloc.so
enabled libpq and psqlodbc.so. It seems, that malloc() and free()
operations are correct,
but the libdmalloc internal memory structures are incorrect with isql.

I don't know the reason, but that seems to be the problem, that I have
found.

isql crashes under conninfo_parse() on line "free(buf)".
buf = malloc() and free(buf) seem to match each other (checked with gdb).
So it seems, that the problem relates with internal libdmalloc
implementation.

I had to modify libpq by inserting a header file into every C file and I
modified
Makefile to link libpq with libdmallocth.so. Even though libdmalloc crashes
often (at least dlclose() incompatibility), it seems to be a good tool
for searching memory
leaks even inside an ODBC driver: it tells the C file and the line of
the code, where the
memory leak happened.

Marko Ristola

Dave Page wrote:

Show quoted text

Forwarded to -bugs in case it gets missed.

This looks like it might be an issue to me, though I may well have
overlooked something in my brief look at the code.

Regards, Dave

-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marko Ristola
Sent: 01 August 2005 18:15
To: Joel Fradkin
Cc: 'James Dornan'; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] IIS Postgres ASP ADO - Problem

I found a crashing problem during CONNECT into a database.

Here is the problem description:

Used Environment:
libpq-API under PostgreSQL 8.0.3
CVS HEAD of psqlodbc

libpq does have a problem with freeing memory, that has not
been alloced
with malloc()!

Here is the problem (I don't know, wether the PostgreSQL CVS
HEAD has a
fix for this):

postgresql-8.0.3/src/interfaces/libpq/fe-connect.c, function
conninfo_parse():

/* Make a working copy of PQconninfoOptions */
options = malloc(sizeof(PQconninfoOptions));
...
memcpy(options, PQconninfoOptions,
sizeof(PQconninfoOptions));

Unfortunately PQconninfoOptions[] contains only char*val
style pointers
instead of
char val[32] type character containers.
Because of this, the assumption, that memcpy() is enough to copy the
structure, is not
true anymore. You should NOT copy a static structure this way!

Working code would be something like this:

options = malloc(sizeof(PQconninfoOptions));
memcpy(options, PQconninfoOptions, sizeof(PQconninfoOptions));
for (i=0; PQconninfoOptions[i].val != NULL; i++) {
options[i].val = strdup(PQconninfoOptions[i].val);
... same for all other values
}
NULL termination.

Because of this, isql fails with me at the beginning, maybe because
dmalloc library, that I use for testing, discovered the problem.

Marko Ristola

Joel Fradkin wrote:

James,

The odbc is not working well for me (I can connect but get

intermittent

issues of the IIS server locking up in regards to connectivity).
My understanding is the snapshot version is the best odbc

out at this time.

Also can you connect via pgadmin (IE have the hba and config

files set to

allow external connections)?

My conection is not using dsn, but I did get dsn to work in testing.
My dsnless string is

Session("StringConn") =
"DRIVER={PostgreSQL};DATABASE=wazagua;SERVER=192.168.123.121;

PORT=5432;UID=p

ostgres;PWD=;ReadOnly=0;Protocol=6.4;FakeOidIndex=0;ShowOidCo

lumn=0;RowVersi

oning=0;ShowSystemTables=0;ConnSettings=;Fetch=100;Socket=409

6;UnknownSizes=

0;MaxVarcharSize=254;MaxLongVarcharSize=8190;Debug=0;CommLog=

0;Optimizer=1;K

sqo=1;UseDeclareFetch=0;TextAsLongVarchar=1;UnknownsAsLongVar

char=0;BoolsAsC

har=1;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;LF

Conversion=1;Up

datableCursors=1;DisallowPremature=0;TrueIsMinus1=0;BI=0;Byte

aAsLongVarBinar

y=0;UseServerSidePrepare=0"

My test using dsn used
Session("StringConn") ="DSN=postgresql;" & _
"UID=postgres;" & _
"PWD=;" & _
"Database=wazuni;"

asp code to use connection is :
dim Arec, Acmd, SQL ,AConn
set Arec = server.CreateObject("ADODB.Recordset")
Set AConn = Server.CreateObject("ADODB.CONNECTION")
set Acmd = server.CreateObject("ADODB.Command")
AConn.ConnectionTimeOut=30
AConn.commandtimeout=30
AConn.Open Session("StringConn")

For .net I use the npgsql .net objects.

Hope this helps you.

Joel Fradkin

-----Original Message-----
From: James Dornan [mailto:james@catch22.com]
Sent: Sunday, July 31, 2005 4:44 PM
To: jfradkin@wazagua.com
Subject: IIS Postgres ASP ADO - Problem

I noticed more than a few post from you about trying to

get Postgres

working with ODBC.
I'm hoping that maybe you would share some of that information. I am
running IIS under
windos 2003 server, and the latest(8.0.3) Postgres server on

the same

machine. I cannot
connect no matter what I do. I have tried everything.

The funny part is that I'm not new to ODBC, or windows.

I've worked

with windows all
the time, but just can't figure this one out. I've tried using a
connection string, a DSN,
reinstalling, IIS, Postgres, ODBC drivers, MDAC, Jet, and so

on. I still

have the same problem.
The odbc drive and it's dependant DDLs are in the path. The

permisions

are wide open
(for testing this specific problem).

Is there any insight you could shed on the dark world of

windows and

ODBC, where feed-
back is rare.

Thanks for any help you can provide.

-- James

---------------------------(end of

broadcast)---------------------------

TIP 2: Don't 'kill -9' the postmaster

---------------------------(end of
broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dave Page (#1)
Re: Libpq free bug? (Was: [ODBC] IIS Postgres ASP ADO - Problem)

"Dave Page" <dpage@vale-housing.co.uk> writes:

Forwarded to -bugs in case it gets missed.
This looks like it might be an issue to me, though I may well have
overlooked something in my brief look at the code.

There's nothing wrong with that code. The only modifiable values in the
record are the "val" pointers, which are handled correctly. See the
comment:

* PQconninfoOptions[] is a constant static array that we use to initialize
* a dynamically allocated working copy. All the "val" fields in
* PQconninfoOptions[] *must* be NULL. In a working copy, non-null "val"
* fields point to malloc'd strings that should be freed when the working
* array is freed (see PQconninfoFree).

regards, tom lane

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Marko Ristola (#2)
Re: Libpq free bug? (Was: [ODBC] IIS Postgres ASP ADO - Problem)

Marko Ristola <Marko.Ristola@kolumbus.fi> writes:

I don't know the reason, but that seems to be the problem, that I have
found.

isql crashes under conninfo_parse() on line "free(buf)".

In my experience, this is probably a symptom of some code scribbling
past the end of a malloc'd chunk of memory. What is usually right after
the end of a malloc'd chunk is a portion of malloc's own data
structures, and clobbering that data structure is highly likely to
result in a crash in a later call to malloc, free, or related routines.

You might try running the code under something like Electric Fence.

regards, tom lane

#5Dave Page
dpage@pgadmin.org
In reply to: Tom Lane (#4)
Re: Libpq free bug? (Was: [ODBC] IIS Postgres ASP ADO - Problem)

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 02 August 2005 00:36
To: Dave Page
Cc: pgsql-bugs@postgresql.org; pgsql-odbc@postgresql.org
Subject: Re: [BUGS] Libpq free bug? (Was: [ODBC] IIS Postgres
ASP ADO - Problem)

"Dave Page" <dpage@vale-housing.co.uk> writes:

Forwarded to -bugs in case it gets missed.
This looks like it might be an issue to me, though I may well have
overlooked something in my brief look at the code.

There's nothing wrong with that code. The only modifiable
values in the
record are the "val" pointers, which are handled correctly. See the
comment:

* PQconninfoOptions[] is a constant static array that we use
to initialize
* a dynamically allocated working copy. All the "val" fields in
* PQconninfoOptions[] *must* be NULL. In a working
copy, non-null "val"
* fields point to malloc'd strings that should be freed when
the working
* array is freed (see PQconninfoFree).

Ahh, missed that. Thanks Tom.

Regards, Dave