segfault in SQLSpecialColumns when table name is null string

Greetings,

This message arises from LibreOffice bug report
"SIGSEGV: ODBC to PostgreSQL, renaming column in SELECT list"
<https://bugs.freedesktop.org/show_bug.cgi?id=50849>, but I shall try
not to make you read that report.

Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
segfault by calling SQLSpecialColumns with a null string for the table
name. This call is, of course, a strange thing to do, and I cannot
imagine any good result. Still, a segfault seems a disproportionate
punishment for doing something silly.

The segfault happens in SQLSpecialColumns at odbcapi.c line 790, which reads
if (SQL_SUCCESS == ret && 0 == QR_get_num_total_tuples(SC_get_Result(stmt)))
The condition tries to dereference stmt->result, which is NULL.

Along the way to this result, PGAPI_SpecialColumns at info.c lines
2783 through 2786 detects the bad table name and does an early return.
But the return value SQL_SUCCESS seems wrong. When I used gdb to
fudge the return value to SQL_ERROR, there was no segfault.

Do you need more information? Can I do something else to help?

Thank you, all for your attention.
Terry.

( I tried earlier to send this message before my address was
subscribed, and that earlier attempt is waiting for moderation. If
this attempt gets through, I shall ask to moderator to cancel the
first attempt. I apologize for the duplication or confusion. )

On Tue, Jul 10, 2012 at 08:22:52AM -0400, Terrence Enger wrote:

> Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
> driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
> and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
> segfault by calling SQLSpecialColumns with a null string for the table
> name. This call is, of course, a strange thing to do, and I cannot
> imagine any good result. Still, a segfault seems a disproportionate
> punishment for doing something silly.

Also, the ultimate reason for this "strange thing" is that

SQLColAttribute( (SQLHANDLE) 0x1ec7850,
(SQLUSMALLINT) 1,
(SQLUSMALLINT) 15,
(SQLPOINTER) 0x1eb2640,
128,
(SQLSMALLINT *) 0x7fffffff97de,
NULL);

where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
returns (writes at 0x1eb2640) an empty string for this query:

SELECT "Num" "Numero", "data" FROM "foo"."Table1"

Similarly, so do the similar calls with SQL_DESC_CATALOG_NAME and
SQL_DESC_SCHEMA_NAME.

By contrast, they do return good information for query

SELECT "Num" AS "Numero", "data" FROM "foo"."Table1"

That is also a bug in the ODBC driver and should IMHO be fixed.

--
Lionel

Hi Terrence,

(2012/07/10 21:22), Terrence Enger wrote:
> Greetings,
>
> This message arises from LibreOffice bug report
> "SIGSEGV: ODBC to PostgreSQL, renaming column in SELECT list"
> <https://bugs.freedesktop.org/show_bug.cgi?id=50849>, but I shall try
> not to make you read that report.
>
> Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
> driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
> and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
> segfault by calling SQLSpecialColumns with a null string for the table
> name. This call is, of course, a strange thing to do, and I cannot
> imagine any good result. Still, a segfault seems a disproportionate
> punishment for doing something silly.
>
> The segfault happens in SQLSpecialColumns at odbcapi.c line 790, which reads
> if (SQL_SUCCESS == ret && 0 == QR_get_num_total_tuples(SC_get_Result(stmt)))
> The condition tries to dereference stmt->result, which is NULL.
>
> Along the way to this result, PGAPI_SpecialColumns at info.c lines
> 2783 through 2786 detects the bad table name and does an early return.
> But the return value SQL_SUCCESS seems wrong.

Seems a real cause of the problem.
I would fix it and commit the change to CVS soon.

regards,
Hiroshi Inoue

Hi、

(2012/07/10 23:27), Lionel Elie Mamane wrote:
> On Tue, Jul 10, 2012 at 08:22:52AM -0400, Terrence Enger wrote:
>
>> Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
>> driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
>> and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
>> segfault by calling SQLSpecialColumns with a null string for the table
>> name. This call is, of course, a strange thing to do, and I cannot
>> imagine any good result. Still, a segfault seems a disproportionate
>> punishment for doing something silly.
>
> Also, the ultimate reason for this "strange thing" is that
>
> SQLColAttribute( (SQLHANDLE) 0x1ec7850,
> (SQLUSMALLINT) 1,
> (SQLUSMALLINT) 15,
> (SQLPOINTER) 0x1eb2640,
> 128,
> (SQLSMALLINT *) 0x7fffffff97de,
> NULL);
>
> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
> returns (writes at 0x1eb2640) an empty string for this query:
>
> SELECT "Num" "Numero", "data" FROM "foo"."Table1"

What is your environment e.g. the version of your PG server
or the version of your psqlodbc?

regards,
Hiroshi Inoue

On Sun, Jul 15, 2012 at 06:50:27AM +0900, Hiroshi Inoue wrote:
> (2012/07/10 23:27), Lionel Elie Mamane wrote:

>>> Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
>>> driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
>>> and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
>>> segfault by calling SQLSpecialColumns with a null string for the table
>>> name. This call is, of course, a strange thing to do, and I cannot
>>> imagine any good result. Still, a segfault seems a disproportionate
>>> punishment for doing something silly.

>> Also, the ultimate reason for this "strange thing" is that

>> SQLColAttribute( (SQLHANDLE) 0x1ec7850,
>> (SQLUSMALLINT) 1,
>> (SQLUSMALLINT) 15,
>> (SQLPOINTER) 0x1eb2640,
>> 128,
>> (SQLSMALLINT *) 0x7fffffff97de,
>> NULL);

>> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
>> returns (writes at 0x1eb2640) an empty string for this query:

>> SELECT "Num" "Numero", "data" FROM "foo"."Table1"

> What is your environment e.g. the version of your PG server
> or the version of your psqlodbc?

On Debian GNU/Linux amd64, Debian packages.

Client:
unixodbc 2.2.14p2-5
psqlodbc 09.01.0100
libpq5 9.1.3
Server:
postgresql 9.0.6

Terrence is getting the same problem with (on Ubunty Natty 11.04):

unixodbc 2.2.14p2-2ubuntu1
postgresql 8.4.12-0ubuntu11.04
odbc-postgresql 1:08.03.0200-1.2

I haven't directly checked that SQLColAttribute returns an empty
string on Terrence's system, but since LibreOffice crashes in the same
conditions, I presume the cause is the same than on my system,
i.e. SQLColAttribute returns an empty string.

--
Lionel

(2012/07/15 14:02), Lionel Elie Mamane wrote:
> On Sun, Jul 15, 2012 at 06:50:27AM +0900, Hiroshi Inoue wrote:
>> (2012/07/10 23:27), Lionel Elie Mamane wrote:
>
>>>> Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
>>>> driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
>>>> and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
>>>> segfault by calling SQLSpecialColumns with a null string for the table
>>>> name. This call is, of course, a strange thing to do, and I cannot
>>>> imagine any good result. Still, a segfault seems a disproportionate
>>>> punishment for doing something silly.
>
>>> Also, the ultimate reason for this "strange thing" is that
>
>>> SQLColAttribute( (SQLHANDLE) 0x1ec7850,
>>> (SQLUSMALLINT) 1,
>>> (SQLUSMALLINT) 15,
>>> (SQLPOINTER) 0x1eb2640,
>>> 128,
>>> (SQLSMALLINT *) 0x7fffffff97de,
>>> NULL);
>
>>> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
>>> returns (writes at 0x1eb2640) an empty string for this query:
>
>>> SELECT "Num" "Numero", "data" FROM "foo"."Table1"
>
>> What is your environment e.g. the version of your PG server
>> or the version of your psqlodbc?
>
> On Debian GNU/Linux amd64, Debian packages.
>
> Client:
> unixodbc 2.2.14p2-5
> psqlodbc 09.01.0100
> libpq5 9.1.3
> Server:
> postgresql 9.0.6

SQLColattribute returns non null string here under Windows environment.
Well how are you setting odbc.ini?

regards,
Hiroshi Inoue

On Mon, Jul 16, 2012 at 12:50:40AM +0900, Hiroshi Inoue wrote:
> (2012/07/15 14:02), Lionel Elie Mamane wrote:
>> On Sun, Jul 15, 2012 at 06:50:27AM +0900, Hiroshi Inoue wrote:
>>> (2012/07/10 23:27), Lionel Elie Mamane wrote:

>>>> Also, the ultimate reason for this "strange thing" is that

>>>> SQLColAttribute( (SQLHANDLE) 0x1ec7850,
>>>> (SQLUSMALLINT) 1,
>>>> (SQLUSMALLINT) 15,
>>>> (SQLPOINTER) 0x1eb2640,
>>>> 128,
>>>> (SQLSMALLINT *) 0x7fffffff97de,
>>>> NULL);

>>>> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
>>>> returns (writes at 0x1eb2640) an empty string for this query:

>>>> SELECT "Num" "Numero", "data" FROM "foo"."Table1"

>>> What is your environment e.g. the version of your PG server
>>> or the version of your psqlodbc?

>> On Debian GNU/Linux amd64, Debian packages.

>> Client:
>> unixodbc 2.2.14p2-5
>> psqlodbc 09.01.0100
>> libpq5 9.1.3
>> Server:
>> postgresql 9.0.6

> SQLColattribute returns non null string here under Windows environment.
> Well how are you setting odbc.ini?

[PgSQL tst]
Description = PostgreSQL test
Driver = PostgreSQL Unicode
Trace = No
TraceFile =
Database = lobugs
Servername = pgsql.localdomain
Username =
Password =
Port = 5432
Protocol = 6.4
ReadOnly = No
RowVersioning = No
ShowSystemTables = No
ShowOidColumn = No
FakeOidIndex = No
ConnSettings =

odbcinst.ini:

[PostgreSQL Unicode]
Description = PostgreSQL ODBC driver (Unicode version)
Driver = psqlodbcw.so
Setup = libodbcpsqlS.so
Debug = 0
CommLog = 1
UsageCount = 1

--
Lionel

(2012/07/16 1:40), Lionel Elie Mamane wrote:
> On Mon, Jul 16, 2012 at 12:50:40AM +0900, Hiroshi Inoue wrote:
>> (2012/07/15 14:02), Lionel Elie Mamane wrote:
>>> On Sun, Jul 15, 2012 at 06:50:27AM +0900, Hiroshi Inoue wrote:
>>>> (2012/07/10 23:27), Lionel Elie Mamane wrote:
>
>>>>> Also, the ultimate reason for this "strange thing" is that
>
>>>>> SQLColAttribute( (SQLHANDLE) 0x1ec7850,
>>>>> (SQLUSMALLINT) 1,
>>>>> (SQLUSMALLINT) 15,
>>>>> (SQLPOINTER) 0x1eb2640,
>>>>> 128,
>>>>> (SQLSMALLINT *) 0x7fffffff97de,
>>>>> NULL);
>
>>>>> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
>>>>> returns (writes at 0x1eb2640) an empty string for this query:
>
>>>>> SELECT "Num" "Numero", "data" FROM "foo"."Table1"
>
>>>> What is your environment e.g. the version of your PG server
>>>> or the version of your psqlodbc?
>
>>> On Debian GNU/Linux amd64, Debian packages.
>
>>> Client:
>>> unixodbc 2.2.14p2-5
>>> psqlodbc 09.01.0100
>>> libpq5 9.1.3
>>> Server:
>>> postgresql 9.0.6
>
>> SQLColattribute returns non null string here under Windows environment.
>> Well how are you setting odbc.ini?
>
> [PgSQL tst]
> Description = PostgreSQL test
> Driver = PostgreSQL Unicode
> Trace = No
> TraceFile =
> Database = lobugs
> Servername = pgsql.localdomain
> Username =
> Password =
> Port = 5432
> Protocol = 6.4
> ReadOnly = No
> RowVersioning = No
> ShowSystemTables = No
> ShowOidColumn = No
> FakeOidIndex = No
> ConnSettings =

Please set the following.

Protocol = 7.4

Setting

UseServerSidePrepare = 1

is also recommended.

regards,
Hiroshi Inoue

On Mon, Jul 16, 2012 at 06:04:23AM +0900, Hiroshi Inoue wrote:
> (2012/07/16 1:40), Lionel Elie Mamane wrote:
>> On Mon, Jul 16, 2012 at 12:50:40AM +0900, Hiroshi Inoue wrote:
>>> (2012/07/15 14:02), Lionel Elie Mamane wrote:
>>>> On Sun, Jul 15, 2012 at 06:50:27AM +0900, Hiroshi Inoue wrote:
>>>>> (2012/07/10 23:27), Lionel Elie Mamane wrote:

>>>>>> Also, the ultimate reason for this "strange thing" is that

>>>>>> SQLColAttribute( (SQLHANDLE) 0x1ec7850,
>>>>>> (SQLUSMALLINT) 1,
>>>>>> (SQLUSMALLINT) 15,
>>>>>> (SQLPOINTER) 0x1eb2640,
>>>>>> 128,
>>>>>> (SQLSMALLINT *) 0x7fffffff97de,
>>>>>> NULL);

>>>>>> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
>>>>>> returns (writes at 0x1eb2640) an empty string for this query:

>>>>>> SELECT "Num" "Numero", "data" FROM "foo"."Table1"

>>>>> What is your environment e.g. the version of your PG server
>>>>> or the version of your psqlodbc?

> Please set the following.
> Protocol = 7.4

That is not among the choices offered by ODBCConfig; I can take 6.4,
6.3 or 6.2.

Editing the ~/.odbc.ini file by hand, indeed it "solves" the issue. As
does completely removing the "Protocol = ..." line.

> Setting
> UseServerSidePrepare = 1
> is also recommended.

That is also not among the choices offered by ODBCConfig; I have the
following boolean choices:

ReadOnly
RowVersioning
ShowSystemTables
ShowOidColumn
FakeOidIndex

I'm fairly sure ODBCConfig does not have these options (and possible
values) hardcoded, but gets them by interrogating the driver (or
rather its companion libodbcpsqlS.so?); 't would be a good idea to
keep that in sync with what the actual driver supports.

--
Lionel