[Libreoffice-bugs] [Bug 50849] SIGSEGV: ODBC to PostgreSQL, renaming column in SELECT list

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=50849

Lionel Elie Mamane <lionel at mamane.lu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NOTOURBUG                   |
     Ever Confirmed|0                           |1

--- Comment #11 from Lionel Elie Mamane <lionel at mamane.lu> 2012-07-10 05:35:52 PDT ---
(In reply to comment #10)

> It is the ODBC driver which dereferences the null pointer, and the ODBC
> driver may be the underlying cause.  Still, I suggest that between the
> cause and the dereference, LibreOffice has at least helped the ODBC
> driver to fail by executing a "funny" call.

> In the segfaulting case, ODatabaseMetDataResultSet::openSpecialColumns,
> ODatabaseMetaDataResultSet.cxx:1139, calls SQLSpecialColumns with null
> string and zero for parameters 7 and 8, TableName and TableNameSize.

> Does this suggest that it would be good to look into why LO is doing the
> call with null table name?  Or into why LO is doing this extra call at
> all?

Ah yes, I had missed that; I was so focused on the CatalogName and SchemaName
NULL vs empty string.

Fair enough; LibO should not call it with empty string for TableName, and this
should be fixed.

> A funny thing happened on the way to the crash: In PGAPI_SpecialColumns,
> info.c line 2783 detects the null table name, so line 2785 does
> SC_set_error and then line 2786 returns SQL_SUCCESS.  SQL_SUCCESS sounds
> to me like an outright lie.  If in SQLSPecialColumns I fudge the return
> value to SQL_ERROR, then LibreOffice ...

> (*) Goes on to call SQLSpecialColumns with good catalog, schema, and
>     table names.  This call looks very much like what I remember from
>     the successful query.

> (*) Goes on to display the table data.

> The SQL_SUCCESS sounds to me like a candidate for reporting upstream, as
> does the segfault itself.  LEM, do you agree?

Yes, the segfault, with the explanation about SQL_SUCCESS/SQL_ERROR should be
reported upstream. Could you do that (and CC me)? Thanks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.