Thread: 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