Thread: segfault in SQLSpecialColumns when table name is null string

segfault in SQLSpecialColumns when table name is null string

From
Terrence Enger
Date:
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. )



Re: segfault in SQLSpecialColumns when table name is null string

From
Lionel Elie Mamane
Date:
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

Re: segfault in SQLSpecialColumns when table name is null string

From
Hiroshi Inoue
Date:
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

Re: segfault in SQLSpecialColumns when table name is null string

From
Hiroshi Inoue
Date:
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


Re: segfault in SQLSpecialColumns when table name is null string

From
Lionel Elie Mamane
Date:
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

Re: segfault in SQLSpecialColumns when table name is null string

From
Hiroshi Inoue
Date:
(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



Re: segfault in SQLSpecialColumns when table name is null string

From
Lionel Elie Mamane
Date:
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

Re: segfault in SQLSpecialColumns when table name is null string

From
Hiroshi Inoue
Date:
(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


Re: segfault in SQLSpecialColumns when table name is null string

From
Lionel Elie Mamane
Date:
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